Data security sharing method, client, server, storage medium and program product

Abstract

The invention discloses a data security sharing method and a related product, and relates to the technical field of data security. The sharing method mainly comprises the following steps that: a sender encrypts data to be shared by using an encryption key and stores the encrypted data to a server; a cloud key belonging to a sender in a cloud key management system is used for encrypting a data encryption key, and the authority of a receiver is controlled by issuing authorization to the receiver through the cloud key management system, so that dual protection of the encryption key and data content is realized, only the authorized receiver can decrypt and obtain shared data, and the user experience is improved. And even if the server side cannot decrypt the data of the sender. By adopting the scheme, a sender can safely and conveniently share the data to a specific user, and the data is not easy to obtain by a third party.

Description

Technical Field

[0001] The present application relates to the field of data security technology, and in particular to a data security sharing method. In addition, the present application also relates to a client, a server, a computer-readable storage medium, and a computer program product. Background Art

[0002] Traditional data sharing technology usually uses symmetric keys to encrypt the data that the sender wants to share, and then the receiver decrypts it accordingly. 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 on the network disk, and then 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 together or separately, and decrypts it, and then obtains the plain text of the file, which can be viewed, edited, and other operations.

[0003] In such a solution, on the one hand, once user U1 has shared the file, it is difficult to control the behavior of user U2, and it is difficult to ensure that the file is only shared with the user who wants to share it, and will not be shared with other users. The security of the shared file is also difficult to guarantee. On the other hand, there is a high risk of the decryption key being leaked or obtained by a third party. In other words, the security and controllability of the shared data are relatively poor. Summary of the invention

[0004] One purpose of this application is to provide a data sharing solution so that the sender can share data with designated users safely and conveniently, thereby improving the security and controllability of the shared data.

[0005] The first aspect of the present application provides a method for secure data sharing, the method comprising: a first client responds to a first operation of a sender, encrypts first data to be shared using a first key, and obtains a first data ciphertext; the first client sends the first data ciphertext to a server, so that the server stores the first data ciphertext and records first relationship information, wherein the first relationship information represents the correspondence between the first data ciphertext and the first key ciphertext; the first client responds to a second operation of the sender, generates a second request, and the second request is used to request a cloud key management system to issue an authorization for a specified recipient; wherein the cloud key management system stores a cloud key belonging to the sender, and the first key is encrypted by the cloud key in the cloud key management system to generate a first key ciphertext; the first client sends the second request to the cloud key management system, so that the cloud key management system issues a first authorization for the recipient; wherein the first authorization indicates that the recipient is allowed to call the cloud key, and the first authorization enables the recipient to have the authority to open the first data.

[0006] In combination with the first aspect, in a possible implementation method, before using the first key to encrypt the first data to be shared, it also includes: the first client sends a fourth request to the server in response to the sender's fourth operation, and the fourth request is used to request to create a root folder for the sender; wherein the root folder created by the server allows the data to be shared to be added; the first client generates a first key, and the first key is used to encrypt the data added to the root folder; the first client sends the first key to the cloud key management system, so that the cloud key management system uses the cloud key to encrypt the first key and generate a first key ciphertext; the first key ciphertext can be stored by the server; wherein the first operation also includes an operation to determine a specified location under the root folder.

[0007] In combination with the first aspect, in a possible implementation method, it also includes: the first client generates a sixth request in response to the sender's sixth operation; the first client sends the sixth request to the cloud key management system so that the cloud key management system revokes the first authorization of the receiver.

[0008] The second aspect of the present application provides a method for secure data sharing, which includes: a second client receives a first data ciphertext shared by a sender to a receiver from a server; the second client receives a first key from a cloud key management system, wherein the first key is obtained by the cloud key management system based on a first authorization owned by the receiver, calling a cloud key belonging to the sender to decrypt the first key ciphertext; the first authorization indicates that the receiver is allowed to call the cloud key; the second client uses the first key to decrypt the first data ciphertext, obtain and open the first data.

[0009] In combination with the second aspect, in a possible implementation method, before the second client receives the first data ciphertext shared by the sender to the receiver from the server, it also includes: the second client obtains descriptive information of the first data shared with the receiver from the server; the second client sends a third request to the server in response to the receiver's third operation on the first data, requesting the server to search for the first data ciphertext.

[0010] The third aspect of the present application provides a method for secure data sharing, the method comprising: a server receives a first data ciphertext from a sender; the server stores the first data ciphertext and records first relationship information, the first relationship information representing the correspondence between the first data ciphertext and the first key ciphertext; wherein the first key ciphertext is generated by a cloud key management system using a cloud key to encrypt a first key, the cloud key is stored in the cloud key management system and belongs to the sender; the server stores an authorization record, the authorization record includes description information of the first authorization, the first authorization indicates that a specified recipient is allowed to call the cloud key, and the first authorization enables the recipient to have the authority to open the first data.

[0011] In combination with the third aspect, in a possible implementation, before the server receives the first data ciphertext from the sender, the method also includes: the server creates a root folder for the sender in response to the fourth request from the sender; wherein the root folder allows the addition of data to be shared; the server receives and stores a first key ciphertext, wherein the first key is used to encrypt the data added to the root folder; the server stores the first data ciphertext, including: the server adds the first data ciphertext to a specified location under the root folder.

[0012] In combination with the third aspect, in a possible implementation method, the server adds the first data ciphertext to a designated location under the root file, including: the server stores the first data ciphertext in a secondary directory of the sender's physical storage space, and the name of the secondary directory is the data ID of the first data ciphertext; the server records the mapping relationship between the data ID of the first data ciphertext and the logical path of the designated location under the root folder.

[0013] In combination with the third aspect, in a possible implementation, the method also includes: the service side sends the first ciphertext data shared with the recipient to the second client, so that the second client can decrypt the first data ciphertext based on the first authorization possessed by the recipient and open the first data.

[0014] In combination with the third aspect, in a possible implementation method, before the service side sends the first ciphertext data shared with the recipient to the second client, the method also includes: the server sends the description information of the first data shared with the recipient to the second client based on the authorization record; the server searches for the first data ciphertext in response to a third request from the second client; wherein the third request is generated by the second client in response to the third operation of the recipient on the first data.

[0015] In combination with the third aspect, in a possible implementation method, the server searches for the first data ciphertext, including: the server searches for the data ID of the first data based on the logical path of the first data carried in the third request and the mapping relationship between data IDs; the server determines the secondary directory where the first data ciphertext is located in the physical storage space of the sender according to the data ID of the first data.

[0016] In combination with the third aspect, in a possible implementation manner, the method further includes: when the first authorization is revoked by the cloud key management system, the server deletes the description information of the first authorization in the authorization record.

[0017] The fourth 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 first aspect or the second aspect.

[0018] The fifth aspect of the present application provides a server, 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 third aspect.

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

[0020] 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

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

[0022] Figure 2 A flowchart of an exemplary data security sharing method provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0024] The data security sharing scheme of the present application is a multi-layer encryption and authorization scheme based on cloud keys. The encryption key (such as the first key below) is used to encrypt the data to be shared (such as the first data below), and the cloud key belonging to the sender in the cloud key management system is used to encrypt the data encryption key. The cloud key management system issues an authorization (such as the first authorization below) to the receiver to control the authority, thereby achieving dual protection of the encryption key and the data content. Only the authorized receiver can decrypt and obtain the shared data. In addition, by managing the cloud key through the cloud key management system and managing the data ciphertext and the data encryption key ciphertext through the server, the direct exposure of the key can be avoided, and the service side can be prevented from obtaining the key and the corresponding data ciphertext at the same time, thereby achieving end-to-end security. In general, the adoption of this scheme can effectively improve the security and controllability of the shared data.

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

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

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

[0028] For ease of description and distinction, in the embodiments of the present application, the user who shares data is referred to as the sender, and the user whose data is shared is referred to as the receiver; the client used by the sender in this scenario is referred to as the first client, and the client used by the receiver is referred to as the second client. It is understandable that in addition to the above-mentioned user roles and clients, other roles and corresponding clients may be involved in some application scenarios, and this application does not limit this.

[0029] The service side in the embodiment of the present application may include a server and a cloud key management system. The server and the cloud key management system may be located on independent physical servers, or in a server cluster or distributed system consisting of multiple physical servers, or in 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. The present application does not limit its specific product form and its deployment method.

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

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

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

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

[0034] Each user, such as the sender and the receiver, 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.

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

[0036] The following will further introduce the processes of (i) creating a root folder and adding data to the root folder, (ii) creating a cloud key and authorizing the recipient, (iii) the recipient viewing the data in the root folder, and (iv) revoking the authorization given to the recipient. 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.

[0037] (I) Create a root folder and add data to it

[0038] See also Figure 2 , Figure 2 A flowchart of an exemplary data sharing method provided in an embodiment of the present application.

[0039] S101, the first client sends a fourth request to the server in response to a fourth operation of the sender.

[0040] S102: The server creates a root folder for the sender in response to the fourth request.

[0041] When the sender wants to create a folder of his own that can be used to share data, 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 "Create Encrypted Shared Folder" control in the client interface displayed on the first client. In response to the operation of the sender, the first client sends a fourth request to the server.

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

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

[0044] The server creates a root folder to which data can be added. The data added to the root folder can support secure data sharing.

[0045] In some possible implementations, the server assigns a root folder ID for the root folder that can be used for unique identification, and associates the root folder ID with the sender's identity information (such as the sender's account registered on the server, the sender's personal key identifier, etc.), or configures the owner information of the root folder to the sender's identity information, thereby granting ownership of the root folder to the sender.

[0046] In some possible implementations, the fourth request may also include other possible information, such as the name and icon of the root folder. In this way, when the server creates a root folder for the sender, it can use the name carried in the fourth request to name the created root folder and set an icon, so that the user can conveniently define the name, icon and other interface display information of his own root folder.

[0047] As mentioned above, each user can have his or her own personal key. When sending a request to the server or cloud key management system, 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 server or cloud key management system in the request. In this way, after receiving the request, the server or cloud key management system 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 server or cloud key management system will perform other steps required to respond to the request.

[0048] Exemplarily, the sender has his own personal key, and the first client can use the private key in the sender's personal key to sign certain information in the fourth request (such as the sender's identity information, etc.), and then send the signature to the server in the fourth request. The server can obtain the public key of the sender's personal key based on the sender's identity information, such as the sender'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 sender, and the signed information in the fourth request has not been tampered with, and then create a root folder for the sender.

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

[0050] It can also be understood that, through the above method, the sender can also request the server to create other different root folders for it, and this application does not limit this.

[0051] Optionally, after S102, the server may return description information of the root folder to the sender, such as the creation time and name of the root folder, so that the sender can know which root folders he owns.

[0052] S103: The first client generates a first key.

[0053] The first key can be used to encrypt data added to the root folder. The first key can be a key randomly generated by the first client, which can be a symmetric key or an asymmetric key, which is not limited in this application. In some possible implementations, the first key can have a key identifier for uniquely identifying the first key.

[0054] It is understandable that the sender can create multiple root folders, and different root folders can correspond to different first keys. That is, all data in a root folder are encrypted with the same first key, while data in different root folders are encrypted with different first keys, thereby facilitating data sharing and control.

[0055] It should be noted that step S103 can be executed by the first client in response to the aforementioned fourth operation. Step S103 can be executed earlier than the step of sending the fourth request to the server or can be executed synchronously with it. It can also be executed after the root folder is created. The execution order of this step is not limited in this application.

[0056] In some implementations, when step S103 is executed earlier than the step of sending the fourth request to the server, the fourth request may carry the key identifier of the first key, so that the server can associate and record the ID of the root folder and the key identifier of the first key (also referred to as the second relationship information in the embodiment of the present application) after creating the root folder, thereby recording the association between the root folder and the first key. In other implementations, the first client may also wait until the first key or the first key ciphertext is generated in a subsequent step, and then the server can record the association between the root folder and the first key.

[0057] S104, the first client responds to the first operation of the sender and encrypts the first data to be shared using the first key to obtain a first data ciphertext.

[0058] The data in the embodiments of the present application may include data assets such as documents, pictures, videos, and audios, and the present application does not limit the specific data format thereof. The first data here may be data in any possible form.

[0059] There may be multiple levels of directory structures under the root folder, for example, there may be other secondary folders, tertiary folders, etc. under the root folder. When the sender wants to add data in the root folder, he can perform an operation on the first client for a specified location under the root folder (for ease of distinction, referred to as the first operation in the embodiment of the present application). For example, the sender clicks the "Add New Content" control in the user interface displayed on the first client, and can directly select the first data to be added in the root folder, or choose to create a secondary, tertiary, etc. folder, and then select the first data to be added in the secondary, tertiary, etc. folder. It is understandable that, whether it is for a root folder or a subordinate folder, etc., the sender can specify the location under the root folder to which the data is to be added through the first operation.

[0060] In response to the sender's operation, the first client encrypts the first data using the first key to obtain the first data ciphertext. It is understandable that when the first data to be shared includes multiple data, the first client encrypts the data using the first key respectively to obtain the corresponding data ciphertext.

[0061] S105, the first client sends a first data ciphertext to the server.

[0062] It is understandable that the first client can simultaneously send description information used to describe the specified location, such as a file-level ID, and the like, together with the first data ciphertext to the server.

[0063] S106, the server adds the first data ciphertext to a designated location under the root folder.

[0064] In some possible implementations, the server may directly store the first data ciphertext in a designated location.

[0065] In some other possible implementations, the server may store the first data ciphertext in the sender's physical storage space and record the logical path of the first data ciphertext in the root folder, thereby decoupling the virtualized logical path and the physical storage path, thereby reducing the storage overhead of the data ciphertext on the server and improving the search performance and efficiency.

[0066] In some implementations, the step of S106 may include:

[0067] S1061, the server stores the first data ciphertext in a secondary directory of the sender's physical storage space, where the name of the secondary directory is the data ID of the first data ciphertext;

[0068] S1062, the server records the mapping relationship between the data ID of the first data ciphertext and the logical path of the designated location under the root folder.

[0069] For example, for example, the aforementioned software product with data asset sharing function may include a user-oriented APP and a server that provides business services for the APP in the background. In addition, there is a cloud key management system on the service side for providing cloud key-related services. The software product can provide users with data storage and secure sharing functions. Each user has an independent storage space on the server side, and can logically create folders and upload data to achieve hierarchical management and fast retrieval of data. In actual physical storage, the server uses a flat structure to store files to improve access speed and retrieval efficiency.

[0070] Assume that user user_123 creates a logical directory structure and uploads files (i.e. data), which mainly include the following contents:

[0071] A folder aa (i.e. the root folder, id: 1) is created in the logical path;

[0072] Created folder bb (id: 2) in aa;

[0073] Uploaded the file cc.txt(id:3) in the bb folder.

[0074] It is understandable that the server has correspondingly executed the above steps of creating a folder and storing files. The server's database records the file / folder name, id, type and other related information, as exemplified below:

[0075] aa is a folder node in the user_123 space, with an id of 1 and a node type of "folder";

[0076] bb is a folder node in the user_123 space, with an id of 2 and a node type of "folder";

[0077] cc.txt is a file node in the user_123 space, with an id of 3 and a node type of "file".

[0078] The relationship between the logical path and physical path of the file cc.txt is as follows:

[0079] Logical path: / aa / bb / cc.txt. This path is only recorded in the database and can be displayed by the client, showing the user as a hierarchical structure of the file, making it easier for the user to manage and search on the client.

[0080] Physical storage path: / user_123 / 3 / cc.txt. In physical storage, the server stores cc.txt in a subdirectory (i.e. / 3) under the root folder of user_123 with the file id as the directory name. The physical path of the file itself is / user_123 / 3 / cc.txt.

[0081] In this way, the logical path of the first data ciphertext can be separated from the physical storage path. The logical path records the multi-level structure of the root folder in the server database; the physical path adopts a flat storage structure, all data is stored in user-level directories, and each data is saved in a subdirectory named after its data ID. Based on the data ID and the logical path recorded in the database, a mapping from the logical path to the physical path is established, so that the system can maintain the logical hierarchical management of files under the flat physical structure, and can achieve hierarchical management of data without actually creating logical directories aa and bb. The creation of deep directories on the physical path is avoided, the complexity of the storage structure is reduced, storage resources are saved, and the speed of data search and access is optimized, reducing the search overhead caused by the physical directory hierarchy. This design is particularly suitable for scenarios with large amounts of data storage and complex folder directory structure management.

[0082] In addition, by marking file or folder nodes in the database, management and display of different node types are allowed, thereby realizing logical hierarchical path display without directory creation, while achieving the aforementioned technical effects without affecting the display effect to the user.

[0083] S107, the server records the first relationship information.

[0084] The first relationship information represents the correspondence between the first data ciphertext and the first key ciphertext. The correspondence can be a direct association or an indirect association, which is not limited in this application. For example, in some implementations, since the server has recorded the association between the root folder and the first key, that is, the aforementioned second relationship information, and the first ciphertext data is added to the specified location under the root folder, even if the server does not record it directly, the correspondence between the two can be represented by the second relationship information, etc.

[0085] (2) Create a cloud key and authorize the recipient

[0086] S201, the first client sends a fifth request to the cloud key management system.

[0087] S202: The cloud key management system generates a cloud key belonging to the sender in response to the fifth request.

[0088] It should be noted that, in some possible implementations, step S201 may be executed by the first client in response to the aforementioned fourth operation. Step S201 may be executed earlier or later than the step of sending the fourth request to the server, or may be executed synchronously with it. This application does not limit the order of execution of these steps.

[0089] The fifth request is used to request the creation of a cloud key belonging to the sender. In some possible implementations, the fifth request may include the sender's identity information. The sender's identity information may exemplarily include one or more information such as the sender's personal key identifier, the sender's account number registered on the server, etc., which can uniquely identify the sender's identity alone or in combination.

[0090] The first client may send the fifth request directly to the cloud key management system, or may request the server to send the fifth request to the cloud key management system, and this application does not limit this.

[0091] The cloud key management system generates a cloud key in response to the fifth request, and the cloud key is always stored in the cloud key management system and will not be transmitted outside the cloud key management system. The cloud key management system can configure the owner information of the cloud key as the identity information of the sender, such as the sender's personal key identifier, etc. In this way, the cloud key can be controlled by the sender's personal key. It is understandable that after the cloud key is created, it can be used for a variety of possible purposes, such as encrypting the first key and other possible keys, data, etc., which is not limited in this application.

[0092] In some possible implementations, the cloud key management system may return description information of the cloud key, such as a key identifier of the cloud key, to the first client so that the first client can subsequently call the cloud key.

[0093] S203: The first client sends the first key to the cloud key management system.

[0094] S204, the cloud key management system uses the cloud key to encrypt the first key to generate a first key ciphertext.

[0095] In some implementations, the first client sends the first key, a key identifier of the cloud key, and a personal key of the sender to the cloud key management system to request to call the cloud key in the cloud key management system to encrypt the first key.

[0096] The first key ciphertext generated by the cloud key management system can be stored in a variety of different locations. In some implementations, the cloud key management system can return the description information of the first key ciphertext to the first client, and store the first key ciphertext in the cloud key management system or on the server. In other implementations, the cloud key management system can return the first key ciphertext to the first client, and the first client can store it by itself, send it to the server, or other possible media for storage.

[0097] S205: The first client generates a second request in response to the second operation of the sender.

[0098] When the sender wants to share the root data with a certain user and authorizes the user, the sender can perform an operation on the first client (for the sake of distinction, referred to as the second operation in the embodiment of the present application), and the second operation includes an operation of specifying at least one recipient. For example, the sender clicks the "Add Member" control in the user interface displayed on the first client, and then selects one or more users as recipients. In response to the operation of the sender, the first client generates a second request.

[0099] The second request is used to request the cloud key management system to issue an authorization for the specified recipient. In some implementations, the first client can obtain the identity information of the specified recipient from the server, such as the account number registered by the recipient on the server, the personal key identifier of the recipient, etc., and then put the identity information of the recipient, the key identifier of the cloud key, and the sender's personal key identifier and other sender's identity information together in the second request.

[0100] S206: The first client sends a second request to the cloud key management system.

[0101] S207, the cloud key management system issues a first authorization to the recipient.

[0102] The data structure of the authorization issued by the cloud key management system can be implemented in multiple 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.

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

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

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

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

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

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

[0109] 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 cloud key management system 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.

[0110] It can be seen that if a request is made to authorize the cloud key to the recipient, the cloud key management system will issue a first authorization to the recipient accordingly.

[0111] The first authorization indicates that the recipient is allowed to call the cloud key. Exemplarily, the authorization target key identifier is the key identifier of the cloud key; the personal key identifier of the authorized person is the personal key identifier of the recipient; and the personal key identifier of the authorizer is the personal key identifier of the sender.

[0112] It is understandable that when multiple recipients are specified in the second request, the cloud key management system can issue corresponding first authorizations to these recipients respectively. Of course, the sender can also repeat the above steps to request to authorize the cloud key to other users, and the user with the corresponding authorization will also become the recipient.

[0113] Optionally, the server can record the root folder and the data added to the root folder, such as the description information of the root folder (such as the folder ID), the data ID of the first data, the storage address of the corresponding first data ciphertext, the time when the first data was added, etc., for subsequent query and use.

[0114] In this way, only authorized client users, such as senders and receivers, can decrypt and open the first data when needed; the server stores the first data ciphertext and the first key ciphertext, but does not have the cloud key, so it is difficult for the server providing business services to view the specific content of the first data; although the cloud key management system stores the cloud key and can decrypt the first key, it does not know what the first key can be used for, and does not have the first data ciphertext, so it is difficult for the cloud key management system to view the specific content of the first data. Therefore, the above solution can achieve end-to-end security effects and further improve the security and privacy of shared files.

[0115] S208, the server may store the authorization record.

[0116] The authorization record includes at least the description information of the aforementioned first authorization (such as the authorization ID), etc. The authorization record may also include the description information of the corresponding root folder (such as the root folder ID), the identity information of the corresponding recipient and sender (such as the account registered by the recipient and sender on the server), etc., for subsequent query and use.

[0117] (III) The recipient views the data in the root folder

[0118] The receiver can view the data shared by each sender. The following takes the receiver opening the first data as an example to illustrate the opening process.

[0119] S305, the second client receives the first data ciphertext shared by the sender to the receiver from the server.

[0120] In some implementations, when the login account of the second client is displayed as the recipient, the server can proactively send the ciphertext of the data shared with the recipient, including the aforementioned first ciphertext of data, to the second client. In other implementations, the server can first send the description information of the data shared with the recipient (such as the root folder name, the name and thumbnail of the data added to the root folder, etc.) to the second client, and the second client can display part or all of the description information on the user interface so that the recipient can select the data in the root folder, determine the data to be opened, and then send the corresponding ciphertext of data to the second client.

[0121] Exemplarily, the step S305 may further include:

[0122] S301, the server sends description information of the first data shared with the recipient to the second client according to the authorization record;

[0123] S302, the second client displays description information of the first data shared with the recipient;

[0124] S303, the second client sends a third request to the server in response to the third operation of the receiver on the first data;

[0125] S304: The server searches for the first data ciphertext in response to the third request.

[0126] When the recipient wants to open a certain data (such as the first data), he can perform an operation on the data on the second client (for the sake of distinction, referred to as the third operation in the embodiment of the present application), such as clicking a file icon or a file name control in the user interface displayed on the second client. The second client generates a third request in response to the recipient's operation. The recipient who is not the root folder cannot even see the root folder and the data therein on his own client.

[0127] The third request is used to request to open the first data ciphertext. In some possible implementations, the third request may include the identity information of the recipient, such as the account number registered by the recipient on the service side or the server, the personal key identifier of the recipient, etc. The third request may also include description information of the first authorization (such as the authorization ID of the first authorization), etc.

[0128] In some possible implementations, if the first data ciphertext is stored in a flat manner by decoupling the logical path and the physical path, then correspondingly, the step of searching the first data ciphertext by the server may include:

[0129] S3041, the server searches for the data ID of the first data based on the logical path of the first data carried in the third request and the mapping relationship between the data IDs;

[0130] S3042, the server determines the secondary directory where the first data ciphertext is located in the sender's physical storage space according to the data ID of the first data.

[0131] For example, still taking the aforementioned user123 as an example, when user user123 wants to access the file cc.txt, the server reads the logical path / aa / bb / cc.txt of the file from the database, obtains the file id 3, and quickly maps it to the physical path / user_123 / 3 / cc.txt, thereby realizing logical hierarchical path management under a flat structure, while ensuring efficient access to files.

[0132] S306, the cloud key management system calls the cloud key to decrypt the first key ciphertext based on the first authorization owned by the recipient to obtain the first key.

[0133] S307: The cloud key management system returns the first key to the second client.

[0134] S308: The second client uses the first key to decrypt the first data ciphertext, obtains and opens the first data.

[0135] In some possible implementations, since all data in a root folder is encrypted using the first key, after the second client obtains the first key, it can be allowed to directly decrypt other files in the root folder and open them within a certain period of time. For example, during the validity period of the recipient's single login, the second client can be allowed to use the first key to decrypt other files in the root folder; and when this login fails, the second client needs to re-initiate a third request to the server.

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

[0137] Optionally, the first key received by the second client is configured to be stored only in the memory of the second client and cannot be read out of the memory.

[0138] In the above implementation, the recipient can open the data added in the root folder because he has the first authorization, while other recipients who are not designated by the root folder cannot obtain the first key because they are not allowed to call the cloud key, and thus cannot decrypt the first data plaintext. That is, the above method can ensure that only authorized recipients can access the data in the corresponding root folder.

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

[0140] (IV) Revocation of Authorization

[0141] In addition to requesting the recipient to issue an authorization, the sender can also request to delete the authorization owned by the recipient to manage data sharing. In some implementations, the sender deleting the recipient may include the following steps S209 to S210.

[0142] S209: The first client generates a sixth request in response to the sixth operation of the sender.

[0143] When the sender wants to prohibit a certain recipient from accessing data in a root folder, the sender can perform an operation on the first client for the recipient's authorization in the root folder (for ease of distinction, referred to as the sixth operation in the embodiment of the present application). For example, the sender clicks on the recipient list corresponding to the first root folder in the user interface displayed on the first client, and then selects one or more recipient authorizations, such as selecting the aforementioned first authorization and clicking the "Delete Authorization" control. In response to the sender's operation, the first client generates an eighth request.

[0144] In some possible implementations, the first client can obtain the identity information and authorization description information of the recipient of the root folder managed by the sender from the service side, and display some of the description information (such as the recipient's account, the validity period of the authorization owned by the recipient, etc.) on the user interface so that the user can perform operations based on the recipient's authorization.

[0145] The sixth request is used to request the revocation of the first authorization of the recipient. In some implementations, the first client may put the identity information of the recipient, the description information of the first authorization, and the sender's identity information such as the sender's personal key identifier in the sixth request.

[0146] S210: The first client sends a sixth request to the cloud key management system.

[0147] S211, the cloud key management system revokes the first authorization of the recipient in response to the sixth request.

[0148] The cloud key management system may directly delete the first authorization, or may set the status of the first authorization from valid to invalid, thereby revoking the first authorization.

[0149] In some possible implementations, the cloud key management system may directly or indirectly notify the server that when the first authorization is revoked by the cloud key management system, the server deletes the description information of the first authorization in the authorization record. In this way, when the recipient subsequently accesses the second client, he or she will not even see the aforementioned root folder and related information on the second client, let alone be able to open the data therein.

[0150] The following is a supplementary explanation of the scheme of the embodiment of the present application applied to an exemplary application scenario. Still taking the aforementioned software product with data asset sharing function as an example, the software product supports the encrypted shared folder function. User user_A can create his own shared folder (corresponding to the aforementioned root folder) on the APP, create secondary, tertiary and other folders in the shared folder, and can upload his own data to any possible location of the shared folder. It is understandable that the data is uploaded after being encrypted and stored by the server to the location specified by user_A under the shared folder. When user user_A needs to share the shared folder with other users such as user_B, user_C, etc., user_B, user_C, etc. can be added as members for the shared folder, and the cloud key management system is requested to issue corresponding authorizations to these members respectively. In this way, users user_B, user_C, etc. who are added as members can view the shared folders shared by user_A on their own APP. It is understandable that user_B, user_C, etc. can not only view the data currently in the shared folder, but if user_A later adds other data to the shared folder, or deletes or modifies the data therein, user_B and user_C can also view it without user_A having to reauthorize.

[0151] User user_A can manage not only the shared folder, but also the number and permissions of members, such as adding or deleting members according to actual needs, that is, issuing authorizations for members or revoking authorizations of members through the cloud key management system. For deleted members, even if they have opened the data in the shared folder before, they will no longer be able to open any data in the shared folder after being deleted, and they will no longer be able to see the relevant information of the shared folder. This method can effectively ensure the security and controllability of shared files, and the management method is flexible and efficient.

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

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

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

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

[0156] The present application also provides a server, which may include:

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

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

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

[0160] The method 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 method.

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

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

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

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

[0165] 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 data security sharing method, characterized in that: The method comprises: In response to the first operation of the sender, the first client encrypts the first data to be shared using the first key to obtain the first data ciphertext; The first client sends a first data ciphertext to the server, so that the server stores the first data ciphertext and records first relationship information, where the first relationship information represents a corresponding relationship between the first data ciphertext and the first key ciphertext; The first client generates a second request in response to the second operation of the sender, wherein the second request is used to request the cloud key management system to issue an authorization for the designated recipient; wherein the cloud key management system stores a cloud key belonging to the sender, and the first key is encrypted by the cloud key in the cloud key management system to generate a first key ciphertext; The first client sends the second request to the cloud key management system so that the cloud key management system issues a first authorization for the recipient; wherein the first authorization indicates that the recipient is allowed to call the cloud key, and the first authorization enables the recipient to have the authority to open the first data.

2. The method according to claim 1, characterized in that Before using the first key to encrypt the first data to be shared, the method further includes: In response to the fourth operation of the sender, the first client sends a fourth request to the server, wherein the fourth request is used to request to create a root folder for the sender; wherein the root folder created by the server allows adding data to be shared; The first client generates a first key, where the first key is used to encrypt data added to the root folder; The first client sends the first key to the cloud key management system, so that the cloud key management system uses the cloud key to encrypt the first key and generate a first key ciphertext; the first key ciphertext can be stored by the server; The first operation also includes an operation of determining a designated location under a root folder.

3. The method according to claim 1, characterized in that Also includes: The first client generates a sixth request in response to a sixth operation of the sender; The first client sends the sixth request to the cloud key management system, so that the cloud key management system revokes the first authorization of the recipient.

4. A data security sharing method, characterized in that: The method comprises: The second client receives the first data ciphertext shared by the sender to the receiver from the server; The second client receives a first key from the cloud key management system, wherein the first key is obtained by the cloud key management system calling a cloud key belonging to the sender to decrypt the first key ciphertext based on a first authorization owned by the recipient; the first authorization indicates that the recipient is allowed to call the cloud key; The second client uses the first key to decrypt the first data ciphertext, obtains and opens the first data.

5. The method according to claim 4, characterized in that Before the second client receives the first data ciphertext shared by the sender to the receiver from the server, the process further includes: The second client obtains description information of the first data shared with the recipient from the server; In response to the receiver's third operation on the first data, the second client sends a third request to the server to request the server to search for the first data ciphertext.

6. A method for secure data sharing, characterized in that: The method comprises: The server receives the first data ciphertext from the sender; The server stores the first data ciphertext and records first relationship information, wherein the first relationship information represents a corresponding relationship between the first data ciphertext and the first key ciphertext; wherein the first key ciphertext is generated by encrypting the first key using a cloud key by a cloud key management system, and the cloud key is stored in the cloud key management system and belongs to the sender; The server stores the authorization record, which includes description information of the first authorization. The first authorization indicates that the designated recipient is allowed to call the cloud key. The first authorization enables the recipient to have the authority to open the first data.

7. The method according to claim 6, characterized in that Before the server receives the first data ciphertext from the sender, the method further includes: The server creates a root folder for the sender in response to the fourth request from the sender; wherein the root folder allows adding data to be shared; The server receives and stores a first key ciphertext, where the first key is used to encrypt data added to the root folder; The server stores the first data ciphertext, including: the server adds the first data ciphertext to a designated location under the root folder.

8. The method according to claim 7, characterized in that The server adds the first data ciphertext to a specified location under the root file, including: The server stores the first data ciphertext in a secondary directory of the sender's physical storage space, where the name of the secondary directory is the data ID of the first data ciphertext; The server records the mapping relationship between the data ID of the first data ciphertext and the logical path of the designated location under the root folder.

9. The method according to any one of claims 6 to 8, characterized in that: The method further comprises: The service side sends the first ciphertext data shared with the recipient to the second client, so that the second client can decrypt the first data ciphertext based on the first authorization owned by the recipient and open the first data.

10. The method according to claim 9, characterized in that Before the service side sends the first ciphertext data shared with the recipient to the second client, the method further includes: The server sends, to the second client according to the authorization record, description information of the first data shared with the recipient; The server searches for the first data ciphertext in response to a third request from the second client; wherein the third request is generated by the second client in response to the third operation of the receiver on the first data.

11. The method according to claim 10, characterized in that The server searches for the first data ciphertext, including: The server side searches for the data ID of the first data based on the logical path of the first data carried in the third request and the mapping relationship between data IDs; The server determines the secondary directory where the ciphertext of the first data is located in the physical storage space of the sender according to the data ID of the first data.

12. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: When the first authorization is revoked by the cloud key management system, the server deletes the description information of the first authorization in the authorization record.

13. 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 1 to 3; or to implement the method of any one of claims 4 to 5.

14. A server, 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 6 to 12.

15. 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 5, or the method according to any one of claims 6 to 23.

16. 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 5, or the method according to any one of claims 6 to 12.

Images