CN119788391A

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

Info

Publication number: CN119788391A
Application number: CN202411990694.8A
Authority: CN
Inventors: 孙吉平
Original assignee: Beijing Senseshield Technology Co Ltd
Current assignee: Beijing Senseshield Technology Co Ltd
Priority date: 2024-12-31
Filing date: 2024-12-31
Publication date: 2025-04-08

Abstract

The application discloses a data security sharing method and related products, and relates to the technical field of data security. The sharing method mainly comprises the steps that a sender encrypts data to be shared by using an encryption key and stores the encrypted data to a server, the cloud key management system is used for encrypting the data encryption key by using a cloud key belonging to the sender, and the authority of the receiver is controlled by issuing authority to the receiver through the cloud key management system, so that double protection of the encryption key and the data content is realized, and only the receiver with the authority can decrypt the shared data, and even the server cannot decrypt the data of the sender. By adopting the scheme, the sender can safely and conveniently share the data to the specific user, and the data is not easy to acquire by a third party.

Description

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

Technical Field

The application relates to the technical field of data security, in particular to a data security sharing method. The application further relates to a client, a server, a computer-readable storage medium and a computer program product.

Background

Conventional data sharing techniques typically employ a symmetric key to encrypt data to be shared by a sender and then decrypt it accordingly by a receiver. For example, in some network disc products, the user U1 wants to share a file to the user U2, which generally includes that the user U1 encrypts the file to be shared on the network disc by using a key and then sends the shared link to the user U2, and then the user U2 obtains the encrypted file from the network disc through the shared link, and receives the decryption key and decrypts the encrypted file, and then obtains the plaintext of the file, so that operations such as viewing, editing and the like can be performed.

In such a scheme, on one hand, once the user U1 shares, the behavior of the user U2 is difficult to control, it is difficult to ensure that the file is only shared to the user who wants to share, but not to the other users, and the security of the shared file is also difficult to be ensured. On the other hand, the risk of leakage of the decryption key or acquisition by a third party is high. That is, the security and controllability of the data being shared out is relatively poor.

Disclosure of Invention

The application aims to provide a data sharing scheme, so that a sender can safely and conveniently share data to a designated user, and the safety and the controllability of the shared data are improved.

The first aspect of the application provides a data security sharing method, which comprises the steps that a first client side responds to a first operation of a sender and encrypts first data to be shared by using a first key to obtain a first data ciphertext, the first client side sends the first data ciphertext to a server side to enable the server side to store the first data ciphertext and record first relation information, the first relation information characterizes a corresponding relation between the first data ciphertext and the first key ciphertext, the first client side responds to a second operation of the sender and generates a second request, the second request is used for requesting a cloud key management system to issue authorization for a designated receiver, wherein the cloud key management system stores a cloud key belonging to the sender, the first key is encrypted by the cloud key in the cloud key management system to generate the first key ciphertext, and the first client side sends the second request to the cloud key management system to enable the cloud key management system to issue first authorization for the receiver, and the first request indicates that the first authorization is allowed to call the receiver, and the first data is enabled to have the authorization.

With reference to the first aspect, in one possible implementation manner, before encrypting the first data to be shared by using the first key, the method further comprises the steps that the first client side responds to a fourth operation of a sender and sends a fourth request to the server side, the fourth request is used for requesting to create a root folder for the sender, the root folder created by the server side allows the data to be shared to be added, the first client side generates a first key, the first key is used for encrypting the data added to the root folder, the first client side sends the first key to the cloud key management system to enable the cloud key management system to encrypt the first key by using the cloud key to generate a first key ciphertext, the first key ciphertext can be stored by the server side, and the first operation further comprises the operation of determining a designated position under the root folder.

With reference to the first aspect, in a possible implementation manner, the method further includes the steps that the first client responds to a sixth operation of a sender to generate a sixth request, and the first client sends the sixth request to the cloud key management system to enable the cloud key management system to revoke the first authorization of the receiver.

The second aspect of the application provides a data security sharing method, which comprises the steps that 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, the first key is obtained by calling a cloud key belonging to the sender to decrypt the first key ciphertext based on a first authorization owned by the receiver, the first authorization represents that the receiver is allowed to call the cloud key, and the second client uses the first key to decrypt the first data ciphertext to obtain and open first data.

With reference to the second aspect, in one possible implementation manner, before the second client receives the first data ciphertext shared by the sender to the receiver from the server, the method further includes that the second client obtains description information of the first data shared to the receiver from the server, and the second client responds to a third operation of the receiver for the first data and sends a third request to the server to request the server to search the first data ciphertext.

The third aspect of the application provides a data security sharing method, which comprises the steps that a server receives a first data ciphertext from a sender, the server stores the first data ciphertext and records first relation information, the first relation information represents a corresponding relation between the first data ciphertext and a first key ciphertext, the first key ciphertext is generated by a cloud key management system through encrypting a first key by using a cloud 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 comprises description information of a first authorization, the first authorization represents permission of a specified receiver to call the cloud key, and the first authorization enables the receiver to have authority of opening the first data.

With reference to the third aspect, in one possible implementation manner, before the server receives the first data ciphertext from the sender, the method further includes the step that the server responds to the fourth request from the sender to create a root folder for the sender, wherein the root folder allows data to be shared to be added, the step that the server receives and stores a first key ciphertext, the first key is used for encrypting the data added to the root folder, and the step that the server stores the first data ciphertext includes the step that the server adds the first data ciphertext to a designated position under the root folder.

With reference to the third aspect, in one possible implementation manner, the step of adding the first data ciphertext to the designated position under the root file by the server includes the step of storing the first data ciphertext into a secondary directory of the physical storage space of the sender by the server, where the name of the secondary directory is a data ID of the first data ciphertext, and the step of recording a mapping relationship between the data ID of the first data ciphertext and a logic path of the designated position under the root folder by the server.

With reference to the third aspect, in a possible implementation manner, the method further includes sending, by a service side, first ciphertext data shared to the receiver to a second client, so that the second client can decrypt the first data ciphertext based on a first authorization owned by the receiver, and open the first data.

With reference to the third aspect, in one possible implementation manner, before the service side sends the first ciphertext data shared to the receiver to the second client side, the method further includes that the service side sends description information of the first data shared to the receiver to the second client side according to the authorization record, the service side responds to a third request from the second client side, searches for the first data ciphertext, and the third request is generated by the second client side responding to a third operation of the receiver on the first data.

In combination with the third aspect, in one possible implementation manner, the server searches the first data ciphertext, which includes that the server searches a data ID of the first data based on a logical path of the first data carried in the third request and a mapping relationship between the data IDs, and determines a secondary directory where the first data ciphertext is located in a physical storage space of the sender according to the data ID of the first data.

With reference to the third aspect, in a possible implementation manner, the method further includes deleting, by a server, description information including the first authorization in the authorization record if the first authorization is revoked by the cloud key management system.

A fourth aspect of the application provides a client comprising a storage unit configured to store predetermined computer instructions, and a processing unit configured to execute the predetermined computer instructions to implement any one of the possible methods of the first or second aspects.

A fifth aspect of the present application provides a server comprising a storage unit configured to store predetermined computer instructions, and a processing unit configured to execute the predetermined computer instructions to implement any one of the possible methods of the third aspect.

A sixth aspect of the application provides a computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to perform any one of the methods of the first, second or third aspects.

A seventh aspect of the application provides a computer program product comprising a computer program which, when run, causes a computer to perform any of the methods of the first, second or third aspects.

Drawings

Fig. 1 is a schematic system architecture diagram of an exemplary application scenario of the present application.

Fig. 2 is a flow chart of an exemplary data security sharing method according to an embodiment of the present application.

Detailed Description

For a clear and complete description of the technical solutions of the present application, reference will now be made to the following examples and accompanying drawings.

The data security sharing scheme of the application is a multi-layer encryption and authorization scheme based on a cloud key, encrypts data to be shared (such as the following first data) by using an encryption key (such as the following first key), encrypts the data encryption key by using the cloud key belonging to a sender in a cloud key management system, and issues authorization (such as the following first authorization) to control the authority for a receiver through the cloud key management system, thereby realizing double protection of the encryption key and the data content, and only the receiver with the authorization can decrypt the shared data. And the cloud key is managed and controlled by the cloud key management system, and the data ciphertext and the data encryption key ciphertext are managed by the server side, so that direct exposure of the key can be avoided, the server side is prevented from acquiring the key and the corresponding data ciphertext at the same time, and end-to-end safety is realized. In general, the scheme can effectively improve the safety and controllability of the shared data.

For easy understanding, an exemplary application scenario architecture diagram of the data sharing method of the present application will be described first, and then steps executed by each interaction end in the application scenario in the data sharing scheme will be described.

Referring to fig. 1, the application scenario may include a client and a service side.

The client in the embodiment of the application can be in the forms of app, applet, webpage end, desktop end and the like, and can be installed, set or embedded on the terminal. The terminals may include, but are not limited to, terminal devices such as cell phones, tablet computers, personal computers (Personal Computer, PCs), wearable devices, internet of things devices, internet of vehicles devices, augmented reality (augmented reality, AR)/Virtual Reality (VR) devices, personal digital assistants (Personal DIGITALASSISTANT, PDA), etc., the application is not limited to the specific product form/type of client and terminal.

For convenience of description and distinction, in the embodiment of the present application, a user who shares data is referred to as a sender, a user who shares data is referred to as a receiver, a client used by the sender in the scenario is referred to as a first client, and a client used by the receiver is referred to as a second client. It will be appreciated that in addition to the user roles and clients described above, other roles and corresponding clients may be involved in some application scenarios, as the application is not limited in this regard.

The service side in the embodiment of the application can comprise a service side and a cloud key management system. The server and the cloud key management system can be respectively positioned on independent physical servers, can be positioned in a server cluster or a distributed system formed by a plurality of physical servers, and can also be positioned in a cloud server or a cloud computing service center for providing services such as cloud services, cloud databases, cloud computing, cloud storage, network services, cloud communication, middleware services, security services, content distribution services, big data, artificial intelligent platforms and the like.

The service end is mainly used for providing business service for the client. Illustratively, in a software product with a data asset sharing function, a client may be developed as an app for users to download and use, while a server provides business services for the client to register, log in, create and/or manage a user's data asset library, and perform business functions of apps such as file upload, download, sharing, etc. Different users can all complete identity registration and login on the server through the client, and then use various service functions in the client according to respective requirements. Optionally, the server may also divide according to the service function and the like when necessary. Illustratively, the service may include an authentication service module, a user service module, and the like.

The cloud key management system is mainly used for providing possible services such as generation, storage, authorization, use management and the like of the cloud key for the client and the server.

It is understood that the server may establish a communication connection with the cloud key management system. The client can be in communication connection with the server for interaction and interact with the cloud key management system through the server, and can also be respectively in communication connection with the server and the cloud key management system for interaction.

For example, in order to be able to invoke a service provided by the cloud key management system, the server may first register in the cloud key management system using a server key for identifying its identity, 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 (ticket) for the user of the client, the ticket can contain ID and other identity information of the user in the cloud key management system, and the ticket is returned to the client. Thus, when the client needs to interact with the cloud key management system, the client can carry the foregoing ticket in the interaction information if necessary, so that the cloud key management system can identify and verify which service end the client corresponds to, and generate and return a user token (UserToken), and in a subsequent period of time, if the client needs to call some function services in the cloud key management system or request the cloud key management system to perform some operations, the user token can be carried, so that the cloud key management system provides necessary services for the client.

Each user of sender, receiver, etc. can own its own personal key to indicate its own identity and to let other interaction end verify its own identity and rights. The personal key may be a pair of asymmetric keys including a corresponding public key and private key. The public key of the personal key may be sent to the service side before use, where registration takes place.

Illustratively, taking the system described in fig. 1 as an example, after a client used by a certain user logs into a server, when a personal key of the user needs to be registered in a cloud key management system, the client may locally generate a pair of asymmetric keys as the personal key of the user. Then, the client carries the public key in the personal key of the user and the user token in the interaction information, so that the cloud key management system registers the public key of the personal key of the user, and then returns a corresponding personal key identifier to the client (keyLabel). The personal key identification may illustratively be a string of characters that the cloud key management system processes and signs using the private key of the cloud key management system. Subsequently, in the process of interaction between the client and the cloud key management system, the personal key identifier can be carried in the interaction information if necessary to indicate the identity of the client and facilitate the verification of the cloud key management system.

The following will describe further the processes of (a) creating a root folder, (b) adding data in the root folder, (c) creating a cloud key, authorizing the recipient, (c) the recipient to view the data in the root folder, and (d) revoking the authorization to the recipient, respectively. It should be noted that the above sequence numbers are not used to limit the execution sequence of the processes and the steps therein, and the execution sequence of the processes and the steps is determined by the internal logic of the scheme.

First, creating a root folder, and adding data in the root folder

Referring to fig. 2, fig. 2 is a flowchart illustrating an exemplary data sharing method according to an embodiment of the present application.

S101, the first client side responds to a fourth operation of the sender and sends a fourth request to the server side.

S102, the server side responds to the fourth request to create a root folder for the sender.

When the sender wants to create a folder that is self-contained and that can be used to share data, he can perform an operation (for ease of distinction, referred to as a fourth operation in the embodiment of the application) on the first client, for example, click on a "create encrypted shared folder" control in the first client display client interface. The first client transmits a fourth request to the server in response to the operation of the sender.

It should be noted that, the operations performed by the user on the client in the embodiments of the present application (for example, the fourth operation herein, and the following first to sixth operations, etc.) may include one operation step, or may include multiple operation steps, which is not limited in this aspect of the present application.

The fourth request is for requesting creation of a root folder for the sender. In some possible implementations, the fourth request may include identity information of the sender. The identity information of the sender may illustratively include one or more of an account number registered by the sender at the server, a name of the sender, a personal key identification of the sender, etc., which can uniquely identify the identity of the sender alone or after combination.

The server establishes a root folder, the root folder allows data to be added, and the data added into the root folder can support data security sharing.

In some possible implementations, the server assigns a root folder ID that can be used for unique identification to the root folder, and associates the root folder ID with the identity information of the sender (e.g., an account number registered by the sender at the server, a personal key identification of the sender, etc.), or configures the owner information of the root folder as the identity information of the sender, so as to assign ownership of the root folder to the sender.

In some possible implementations, other possible information may also be included in the fourth request, such as the name of the root folder, an icon, etc. Therefore, when the root folder is created for the sender, the server can name the created root folder by using the name carried in the fourth request, and set the icon, so that the user can conveniently define the interface display information such as the name, the icon and the like of the root folder.

As described above, each user may have its own personal key, and when sending a request to the server or the cloud key management system, the client may sign some important information in the request by using the private key of the personal key of the corresponding user, and then send the signature to the server or the cloud key management system with the signature carried in the request. In this way, after the server side or the cloud key management system obtains the request, the public key of the personal key of the user can be used to verify the signature carried in the request. If the verification is passed, the user can be considered to be a request initiated by the user, the signed information in the request is not tampered, and then the server or the cloud key management system executes other steps needed to be executed for responding to the request.

Illustratively, the sender has its own personal key, and the first client may sign some information in the fourth request (e.g., identity information of the sender, etc.) using the private key in the sender's personal key, and then send the signature carried in the fourth request to the server. The server may obtain the public key of the personal key of the sender based on the identity information of the sender, for example, the personal key identifier of the sender, firstly use the public key to verify the signature carried in the fourth request, and if the verification passes, the verification can be considered to be the fourth request initiated by the sender, and the signed information in the fourth request is not tampered, and then create a root folder for the sender.

It will be appreciated that, in the following, the corresponding client may also sign the private key of the personal key of each of the users, for example, the request initiated by the user such as the receiver, and the implementation process may be described above, which will not be described in detail.

It will be further appreciated that, in the above manner, the sender may also request the server to create a different root folder for it, which is not limited by the present application.

Optionally, after S102, the server may return description information of the root folder, such as creation time, name, etc. of the root folder to the sender, so that the sender knows which root folders the sender owns.

S103, the first client generates a first key.

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

It will be appreciated that the sender may create a plurality of root folders, and that different root folders may correspond to different first keys. That is, all data under one root folder is encrypted by the same first key, and data under different root folders is encrypted by different first keys, so that sharing and control of data are facilitated.

It should be noted that, the step of S103 may be performed by the first client in response to the fourth operation, and the step of S103 may be performed earlier than or in synchronization with the step of sending the fourth request to the server, or may be performed after the root folder is created, which is not limited by the execution sequence of the steps of the present application.

In some implementations, when the step of S103 is performed 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, after creating the root folder, associates and records the ID of the root folder with the key identifier of the first key (also referred to as second relationship information in the embodiment of the present application), thereby recording the association relationship between the root folder and the first key. In other implementations, the first client may wait until the first key or the first key ciphertext is generated in a subsequent step, and then record, by the server, the association relationship between the root folder and the first key.

And S104, the first client side encrypts the first data to be shared by using the first key in response to the first operation of the sender to obtain a first data ciphertext.

The data in the embodiment of the application can comprise data assets such as documents, pictures, videos, audios and the like by way of example, and the application is not limited to the specific data format. The first data herein may be any possible form of data.

Multiple levels of directory structures may exist under the root folder, for example, other secondary folders, tertiary folders, etc. may also exist under the root folder. When a sender wants to add data in a root folder, it may operate on a first client for a specified location under the root folder (for ease of distinction, this is referred to as a first operation in the embodiment of the present application). For example, the sender may click on the "Add New content" control in the user interface displayed on the first client, either directly select the first data added in the root folder, or select to create a second level, third level, etc. folder, and then select the first data added in the second level, third level, etc. folder. It is understood that the sender can specify which position under the root folder the data is intended to be added to, whether for the root folder or the lower folder or the like, by the first operation.

The first client encrypts the first data using the first key in response to the operation of the sender, resulting in a first data ciphertext. It can be understood that, when the first data to be shared includes a plurality of data, the first client encrypts the data by using the first key respectively, so as to obtain a corresponding data ciphertext.

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

It is understood that the first client may send the description information for describing the specified location, for example, the file-level id, and the like, together with the first data ciphertext to the server.

S106, the server adds the first data ciphertext to the appointed position under the root folder.

In some possible implementations, the server may directly store the first data ciphertext to the specified location.

In other possible implementations, the server may store the first data ciphertext into the physical storage space of the sender, and record the logical path of the first data ciphertext under the root folder, so as to decouple the virtualized logical path and the physical storage path, so that the storage overhead of the data ciphertext on the server is less, and the searching performance and efficiency are higher.

In some implementations, the step of S106 may include:

S1061, the server stores the first data ciphertext into a secondary catalog of a physical storage space of the sender, wherein the name of the secondary catalog is a data ID of the first data ciphertext;

S1062, the server records the mapping relationship between the data ID of the first data ciphertext and the logic path of the designated position under the root folder.

By way of example, a software product with data asset sharing functionality, such as that described above, may include a user-oriented APP, and a server providing business services for the APP in the background. In addition, the service side is provided with a cloud key management system for providing cloud key related services. The software product may provide data storage and secure sharing functionality for users. Each user has independent storage space at the server, can logically create folders and upload data, and realizes hierarchical management and quick retrieval of the data. In actual physical storage, a service end stores files in a flattened structure so as to improve access speed and retrieval efficiency.

Assume that user_123 creates a logical directory structure and uploads a file (i.e., data), consisting essentially of:

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

Folder bb (id: 2) is created in aa;

the file cc.txt (id: 3) is uploaded in the bb folder.

It will be appreciated that the server side performs the steps of creating folders and storing files as described above accordingly. The related information of file/folder name, id, type and the like is recorded in a database of the server side, and is exemplified as follows:

aa is taken as a folder node in the user_123 space, the id is 1, and the node type is "folder";

bb is used as a folder node in the user_123 space, the id is 2, and the node type is "folder";

txt is used as a file node in the user_123 space, id is 3, and node type is "file".

The relationship of the logical path and the physical path of the file cc.txt is mainly as follows:

Logical path:/aa/bb/cc.txt. The path is only recorded in the database, can be displayed by the client and is displayed for the user as a hierarchical structure of the file, so that the user can manage and search on the client conveniently.

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

The method can separate the logic path of the first data ciphertext from the physical storage path, the logic path records the multi-level structure of the root folder in the server database, the physical path adopts a flattened storage structure, all data are stored according to the user-level catalogue, and each data is stored in the subdirectory named by the data ID. Based on the logic paths recorded by the data id and the database, the mapping from the logic paths to the physical paths is established, so that the system keeps the logic hierarchical management of the file under the flattened physical structure, the hierarchical management of the data can be realized under the condition that the logic directories aa and bb are not actually created, the creation of deep-level directories is avoided on the physical paths, the complexity of the storage structure is reduced, the storage resources are saved, the speed of searching and accessing the data is optimized, and the searching cost brought by the physical directory hierarchy is reduced. This design is particularly suited to scenarios of mass data storage and complex folder directory structure management.

In addition, by marking the file or folder nodes in the database, management and display of different node types are allowed, so that the logical hierarchical path display under the condition of no directory creation is realized, and the display effect on a user is not influenced while the technical effect is realized.

S107, the server records the first relation information.

The first relationship information characterizes a correspondence between the first data ciphertext and the first key ciphertext. The correspondence relationship may be a direct association or an indirect association, and the present application is not limited thereto. In some implementations, the server has recorded the association relationship between the root folder and the first key, that is, the aforementioned second relationship information, and the first ciphertext data is added to the designated location under the root folder, so that even if the server does not directly record the association relationship, the corresponding relationship between the root folder and the first key can be represented by the second relationship information.

(II) creating a cloud key, authorizing the recipient

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

S202, the cloud key management system generates a cloud key attributed to the sender in response to the fifth request.

It should be noted that, in some possible implementations, the step of S201 may be performed by the first client in response to the fourth operation, and the step of S201 may be performed earlier or later than the step of sending the fourth request to the server, or may be performed synchronously therewith, and the order of performing the steps is not limited in the present application.

The fifth request is for requesting creation of a cloud key attributed to the sender. In some possible implementations, the identity information of the sender may be included in the fifth request. The identity information of the sender may illustratively include one or more of a personal key identification of the sender, an account number registered by the sender with the server, etc., which information can uniquely identify the identity of the sender, alone or in combination.

The first client may directly send the fifth request to the cloud key management system, or may send the fifth request to the server, so that the server sends the fifth request to the cloud key management system, which is not limited in the present application.

The cloud key management system generates a cloud key in response to the fifth request, the cloud key being maintained in the cloud key management system at all times without being transmitted outside the cloud key management system. The cloud key management system may configure owner information of the cloud key as identity information of the sender, such as personal key identification of the sender, and the like. In this way, the cloud key may be controlled by the sender's personal key. It will be appreciated that this cloud key may be subsequently used for a number of possible purposes after creation, such as encrypting the first key and possibly other keys, data, etc., as the application is not limited in this regard.

In some possible implementations, the cloud key management system may return description information of the cloud key, such as a key identification of the cloud key, to the first client, so that the first client subsequently invokes the cloud key.

S203, the first client sends a first key to the cloud key management system.

S204, the cloud key management system encrypts the first key by using the cloud key to generate a first key ciphertext.

In some implementations, the first client sends the first key, a key identification of the cloud key, and a personal key of the sender to the cloud key management system to request invocation of the cloud key in the cloud key management system to encrypt the first key.

The first key ciphertext generated by the cloud key management system may be stored in a variety of different locations. In some implementations, the cloud key management system may 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 to the server. In other implementations, the cloud key management system may return the first key ciphertext to the first client, which may store itself, send it to the server, or other possible medium for storage.

S205, the first client generates a second request in response to the second operation of the sender.

When the sender wants to share the root data to a certain user, for which authorization, the sender may perform operations on the first client (for convenience of distinction, referred to as a second operation in the embodiment of the present application), the second operation includes an operation of designating at least one recipient. For example, the sender clicks on an "add member" control in a display user interface on the first client, and then selects one or more users as recipients. The first client generates a second request in response to the operation of the sender.

The second request is for requesting the cloud key management system to issue an authorization for the designated recipient. In some implementations, the first client may obtain, from the server, identity information of the specified recipient, e.g., an account number of the recipient registered with the server, a personal key identification of the recipient, etc., and then place the identity information of the recipient, a key identification of the cloud key, and identity information of the sender, e.g., the personal key identification of the sender, in the second request together.

S206, the first client sends a second request to the cloud key management system.

S207, the cloud key management system issues a first authorization for the receiver.

The authorization issued by the cloud key management system can have a data structure with various implementation manners. Illustratively, in some implementations, the authorization includes an authorization ID, an authorization target key identification, a personal key identification of the authorized person. The authorization may also include one or more of personal key identification of the authorizer, information based on the authorization ID, terms of authorization, and the like. Wherein,

The authorization ID is mainly used for uniquely identifying one authorization;

the authorization target key identification is mainly used for describing which cloud key use right is authorized.

The personal key identification of the authorized person is mainly used for describing to whom the use right of the cloud key is authorized, and it is understood that the authorized person here may be a user, a device, other keys, etc.

Personal key identification of authorizer, mainly used for describing which authorizer requests to issue the authorization;

The authorization ID is mainly used for describing which authorization ID of the authorization used by the authorizer to request issuing of the authorization is, that is, the authorizer requests issuing of the current one of the authorizations based on which authorization he owns.

The authorization clause is mainly used for describing the range limitation that the authorized person is allowed to use the cloud key, such as time information, frequency information, operation limitation information and the like.

It should be noted that, in some implementations, when the authorizer is the owner of the target key, it may not be necessary to provide a basis for the authorization ID, i.e., the issued authorization may be empty according to the authorization ID. In other implementations, if the default cloud key management system first issues a corresponding self-authorization for the owner himself, the self-authorization ID issued for the owner may also be used to control the cloud key.

It can be seen that if a request is made to authorize a cloud key to a recipient, the cloud key management system issues a first authorization for the recipient accordingly.

The first authorization represents allowing the recipient to invoke the cloud key. Illustratively, the authorization target key identifier is a key identifier of a cloud key, the personal key identifier of an authorized person is a personal key identifier of a receiver, and the personal key identifier of the authorized person is a personal key identifier of a sender.

It will be appreciated that when multiple recipients are specified in the second request, the cloud key management system may issue respective first grants for the recipients, respectively. Of course, the sender may repeat the above steps to request that the cloud key be authorized to other users, and the user having the corresponding authorization becomes the receiver.

Optionally, the server may record the root folder and records of data added to the root folder, for example, description information (such as folder ID) of the root folder, data ID of the first data, storage address of the corresponding first data ciphertext, addition time of the first data, and so on, for subsequent query and use.

In this way, only the user of the client with rights, e.g. sender, receiver, can decrypt open when needed; the cloud key management system can decrypt the first key although the cloud key management system stores the cloud key, but does not know what the first key can be used for, and does not have the first data ciphertext, so that the cloud key management system also has difficulty in viewing the specific content of the first data. Therefore, the end-to-end safety effect can be achieved by the scheme, and the safety and privacy of the shared files are further improved.

S208, the server may store the authorization record.

The authorization record at least comprises the description information (such as an authorization ID) of the first authorization, and the authorization record can also comprise the description information (such as a root folder ID) of the corresponding root folder, the identity information (such as account numbers registered by the receiver and the sender at the server) of the corresponding receiver and the sender, and the like, so as to facilitate subsequent inquiry and use.

(III) the recipient views the data in the root folder

The recipient can view the data that each sender shares with him. The opening process will be described below taking the example that the recipient opens the first data.

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

In some implementations, when the login account of the second client is displayed as the receiver, the server may actively send the data ciphertext shared to the receiver, including the first data ciphertext, to the second client. In other implementations, the server may first send the description information (e.g., the name of the root folder, the name and thumbnail of the data added in the root folder, etc.) of the data shared to the receiver to the second client, and the second client may display some or all of the description information on the user interface, so that the receiver may select the data of the root folder, determine that the data is desired to be opened, and send the corresponding data ciphertext to the second client.

Illustratively, the step of S305 may further include:

s301, the server side sends description information of first data shared to a receiver to a second client side according to the authorization record;

s302, a second client displays description information of first data shared to a receiver;

S303, the second client responds to a third operation of the receiver aiming at the first data and sends a third request to the server;

S304, the server responds to the third request and searches the first data ciphertext.

When the recipient wants to open a certain data (e.g., the first data), he can perform an operation (for convenience of distinction, referred to as a third operation in the embodiment of the present application) on the second client with respect to the data, for example, click on a file icon or a file name control in a display user interface on the second client. The second client generates a third request in response to the operation of the recipient. Rather than the recipient to whom the root folder corresponds, the root folder and the data therein cannot even be seen on its own client.

The third request is for requesting to open the first data ciphertext. In some possible implementations, the third request may include identity information of the recipient, such as an account number the recipient registers with the service side or server, a personal key identification of the recipient, and so on. The third request may further include description information of the first grant (e.g., an ID of the first grant), etc.

In some possible implementations, if the first data ciphertext adopts a manner of decoupling a logical path and a physical path and flattening storage, the step of searching the first data ciphertext by the server side correspondingly may include:

s3041, the server searches the data ID of the first data based on the logic path of the first data carried in the third request and the mapping relation between the data IDs;

S3042, the server determines the secondary catalog of the first data ciphertext in the physical storage space of the sender according to the data ID of the first data.

Illustratively, taking the foregoing user123 as an example, when the 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 as 3, and rapidly maps to the physical path/user_123/3/cc.txt, thereby implementing logically layered path management under a flattened structure, and simultaneously guaranteeing efficient access of the file.

And S306, the cloud key management system calls Yun Miyao to decrypt the first key ciphertext based on the first authorization owned by the receiver to obtain a first key.

S307, the cloud key management system returns the first key to the second client.

And S308, the second client decrypts the first data ciphertext by using the first key to obtain and open the first data.

In some possible implementations, since all data in a root folder is encrypted with the first key, after the second client obtains the first key, it may be allowed to directly decrypt other files in the root folder and open for a certain period of time. For example, during the validity period of a single login of the receiver, the second client may be allowed to decrypt other files in the root folder by using the first key, and when the login is invalid, the second client needs to initiate a third request to the server again.

In other possible implementations, the first key may be configured to be deleted after use, each time the recipient needs to open a file, the request needs to be reinitiated.

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

In the above implementation manner, the receiver can open the data added in the root folder due to the first authorization, and other specified receivers not being the root folder cannot obtain the first key due to the fact that the cloud key is not allowed to be invoked, so that the first data plaintext cannot be decrypted. That is, in the above manner, it can be ensured that only authorized recipients can access the data in the corresponding root folder.

In some possible implementations, the second client may be configured to prohibit downloads, forwarding, such that the recipient may open, view, or even edit the first data in the second client when possession of a valid first authorization, e.g., write notes on the first data, etc., but not download the first data to other locations, and not forward to others. By adopting the mode, the data sharing safety can be further improved.

(IV) revoking the authorization

In addition to the sender requesting to issue the authorization to the recipient, the sender may also delete the authorization owned by the recipient requesting to manage the data sharing. In some implementations, the sender deletes the recipient, which may include the following steps S209 to S210.

S209, the first client generates a sixth request in response to the sixth operation of the sender.

When a sender wants to prohibit a recipient from accessing data in a root folder, it may operate on the first client with respect to the authorization of the recipient in the root folder (for ease of distinction, referred to as a sixth operation in the embodiment of the present application). For example, the sender clicks on a list of recipients corresponding to a first folder in a user interface displayed on the first client, and then selects one or more of the recipients' authorizations, such as selecting the first authorization previously described, and clicks on the "delete authorization" control. The first client generates an eighth request in response to the operation of the sender.

In some possible implementations, the first client may obtain, from the service side, identity information of the recipient and descriptive information of the authorization of the root folder managed by the sender, and display a portion of the descriptive information (e.g., an account number of the recipient, an authorization-validity period owned by the recipient, etc.) on the user interface so that the user can operate with respect to the authorization of the recipient.

The sixth request is for requesting revocation of the first authorization of the recipient. In some implementations, the first client may place the identity information of the recipient, the description information of the first authorization, and the identity information of the sender such as the sender's personal key identification in the sixth request.

S210, the first client sends a sixth request to the cloud key management system.

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

The cloud key management system may delete the first authorization directly, or may set the state of the first authorization from valid to invalid, so as to revoke the first authorization.

In some possible implementations, the cloud key management system may notify the server directly or indirectly, and in a case that the first authorization is revoked by the cloud key management system, the server deletes the description information including the first authorization in the authorization record. Thus, when the receiver reenters the second client, the receiver can not see the root folder and the related information on the second client, and the data in the root folder can not be opened any more.

The following applies the scheme of the embodiment of the present application to an exemplary application scenario for supplementary explanation. Taking the foregoing software product with data asset sharing functionality as an example, the software product supports the encryption sharing folder functionality. The user_a can create a shared folder (corresponding to the root folder) belonging to the user_a on the APP, create a secondary folder, a tertiary folder and the like in the shared folder, and upload the user_a to any possible location of the shared folder. It can be understood that the data is encrypted and uploaded and stored by the server to the location specified by the user_a under the shared folder. When the user_a needs to share the shared folder with other users, such as user_ B, user _c, the user_ B, user _c may be added as a member for the shared folder, and the cloud key management system may be requested to issue corresponding authorizations for the members respectively. Thus, the user_ B, user _C added as a member can view the shared folder shared by the user_A on the APP of the user. It will be appreciated that not only can user_ B, user _c etc view data that is currently already in the shared folder, but also user_ B, user _c can view if after that user user_a adds other data to the shared folder or deletes, modifies data therein without re-authorization of user_a.

The user_a cannot manage the shared folder, and can also manage the number, authority and the like of the members, for example, the members are added and deleted according to actual requirements, that is, the members are issued with authorization or the authorization of the members is revoked through the cloud key management system. For the deleted member, even if it has opened the data in the shared folder before, it is unable to open any data in the shared folder after it is deleted, and even can no longer see the relevant information of the shared folder. By adopting the mode, the safety and controllability of the shared files can be effectively ensured, the management mode is flexible, and the management efficiency is high.

It will be appreciated that the functionality implemented by the first client and the second client may be partially or fully integrated in a client product when the actual product is developed.

The embodiment of the application also provides a client, which can comprise:

A first storage unit configured to store predetermined computer instructions;

And the first processing unit is configured to run the predetermined computer instructions to realize part or all of the steps realized by the first client and the second client in any one of the foregoing realization modes.

The embodiment of the application also provides a server, which can comprise:

a second storage unit configured to store predetermined computer instructions;

and the second processing unit is configured to run the predetermined computer instructions to realize part or all of the steps realized by the server in any one of the foregoing realization modes.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a computer readable storage medium or computer program product in addition to the methods, clients, and service systems described above.

The methods performed by the service side and the client provided by the embodiments of the present application may be provided as computer-readable storage media. That is, in an embodiment of the present application, there is also provided a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform some or all of the steps in any one implementation of the foregoing method.

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.

Those of ordinary skill in the art will appreciate that the elements and steps of the examples described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It should be understood that, in various embodiments of the present application, the execution sequence of each step should be determined by its function and internal logic, and the size of the sequence number of each step does not mean that the execution sequence is sequential, and does not limit the implementation process of the embodiments.

It should be further understood that, for the sake of clarity in describing the embodiments of the present application, in the embodiments of the present application, the words "first," "second," etc. are used to distinguish between identical or similar items having substantially the same function and effect, or concepts that differ to some degree. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ.

The same or similar parts of the various embodiments in this specification may be referred to each other. Different embodiments may be combined with each other as long as there is no logical conflict.

Claims

1. A method for securely sharing data, the method comprising:

The method comprises the steps that a first client side responds to a first operation of a sender, and encrypts first data to be shared by using a first key to obtain a first data ciphertext;

the method comprises the steps that a first client sends a first data ciphertext to a server, so that the server stores the first data ciphertext and records first relation information, and the first relation information represents the corresponding relation between the first data ciphertext and a first key ciphertext;

The first client responds to a second operation of a sender and generates a second request, wherein the second request is used for requesting a cloud key management system to issue authorization for a designated receiver, a cloud key belonging to the sender is stored in the cloud key management system, 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 receiver, wherein the first authorization indicates that the receiver is allowed to call the cloud key, and the first authorization enables the receiver to have the authority to open the first data.

2. The method of claim 1, further comprising, prior to encrypting the first data to be shared using the first key:

The method comprises the steps that a first client side responds to a fourth operation of a sender and sends a fourth request to a server side, wherein the fourth request is used for requesting to create a root folder for the sender;

the first client generates a first key, wherein the first key is used for encrypting data added into the root folder;

the first client sends the first key to the cloud key management system so that the cloud key management system encrypts the first key by using the cloud key to generate a first key ciphertext;

wherein the first operation further comprises an operation of determining a specified location under the root folder.

3. The method as recited in claim 1, further comprising:

the first client responds to a sixth operation of the sender and generates a sixth request;

the first client sends the sixth request to the cloud key management system to cause the cloud key management system to revoke the first authorization of the recipient.

4. A method for securely sharing data, the method comprising:

The second client receives a first data ciphertext shared by the sender to the receiver from the 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 by calling a cloud key belonging to the sender to decrypt a first key ciphertext based on a first authorization owned by the receiver;

and the second client decrypts the first data ciphertext by using the first key to obtain and open the first data.

5. The method of claim 4, wherein the second client further comprises, before receiving the first ciphertext of data shared by the sender to the recipient from the server:

The second client acquires the description information of the first data shared to the receiver from the server;

and the second client responds to a third operation of the receiver aiming at the first data and sends a third request to a server to request the server to search the first data ciphertext.

6. A method for securely sharing data, the method comprising:

The server receives a first data ciphertext from a sender;

The server side stores the first data ciphertext and records first relation information, wherein the first relation information characterizes the corresponding relation between the first data ciphertext and a first key ciphertext, the first key ciphertext is generated by a cloud key management system by encrypting a first key by using a cloud key, and the cloud key is stored in the cloud key management system and belongs to the sender;

the server side stores an authorization record, wherein the authorization record comprises description information of a first authorization, the first authorization represents that a specified receiver is allowed to call the cloud key, and the first authorization enables the receiver to have the authority of opening the first data.

7. The method of claim 6, wherein before the server receives the first data ciphertext from the sender, the method further comprises:

The server side responds to the fourth request from the sender to create a root folder for the sender, wherein the root folder allows the data to be shared to be added;

the server receives and stores a first key ciphertext, wherein the first key is used for encrypting data added into the root folder;

The server stores the first data ciphertext, wherein the server adds the first data ciphertext to a designated position under the root folder.

8. The method of claim 7, wherein the server adding the first data ciphertext to the specified location under the root file comprises:

The server stores the first data ciphertext into a secondary catalog of a physical storage space of the sender, wherein the name of the secondary catalog is a data ID of the first data ciphertext;

And the server records the mapping relation between the data ID of the first data ciphertext and the logic path of the appointed position under the root folder.

9. The method according to any one of claims 6 to 8, further comprising:

The service side sends first ciphertext data shared to the receiver to a second client side so that the second client side can decrypt the first data ciphertext based on first authorization owned by the receiver and open the first data.

10. The method of claim 9, wherein before the service side sends the first ciphertext data shared to the recipient to the second client, the method further comprises:

the server side sends the description information of the first data shared to the receiver to the second client side according to the authorization record;

The server side responds to a third request from a second client side to search the first data ciphertext, wherein the third request is generated by the second client side responding to a third operation of the receiver on the first data.

11. The method of claim 10, wherein the server searching for the first data ciphertext comprises:

The server side searches the data ID of the first data based on the logic path of the first data carried in the third request and the mapping relation between the data IDs;

and the server determines a secondary catalog of the first data ciphertext in a 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, further comprising:

and deleting the description information comprising the first authorization in the authorization record by the server under the condition that the first authorization is revoked by the cloud key management system.

13. A client-side, which is provided with a client-side, characterized by comprising the following steps:

a storage unit configured to store predetermined computer instructions;

A processing unit configured to run the predetermined computer instructions to implement the method of any one of claims 1 to 3 or to implement the method of any one of claims 4 to 5.

14. A server-side, which is used for a client to send data to a server, characterized by comprising the following steps:

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 6 to 12.

15. A computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 5 or to perform the method of any one of claims 6 to 23.

16. A computer program product comprising a computer program which, when run, causes a computer to perform the method of any one of claims 1 to 5 or to perform the method of any one of claims 6 to 12.