Data protection methods, terminals, systems, storage media, and computer program products

Abstract

This application provides a data protection method, terminal, system, storage medium, and computer program product. The method includes: a first client and a second client establishing a pipe connection through a server; the first client sending a shared data access request to the second client through the pipe connection; wherein the shared data is encrypted data; the first client receiving first key information corresponding to the shared data sent by the second client through the pipe connection, and decrypting and accessing the shared data using the first key information. In this embodiment, during the process of controlling the first client's access to shared data through the second client, messages are transmitted through the pipe connection and are not recorded in the caches of individual terminals, thus ensuring that messages cannot be eavesdropped on or tampered with, and guaranteeing the communication security between the first and second clients.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a data protection method, terminal, system, storage medium, and computer program product. Background Technology

[0002] Protecting shared confidential data accessed via computers is a major concern, and secure encryption is the most effective means of data security. However, files encrypted with traditional encryption techniques must be decrypted before use. According to confidentiality standards, viewing an encrypted file requires decryption to plaintext, viewing the plaintext, and deleting the plaintext. Modifying an encrypted file requires decrypting the ciphertext, modifying the plaintext, saving the plaintext, and then encrypting the plaintext again. This extra work involved in file encryption and decryption slows down computer performance and degrades the user experience. Furthermore, the use of applications inevitably involves the question of whether confidential information is involved, and there is currently no comprehensive and systematic solution for controlling actions involving confidential data. Therefore, a data protection method is needed to ensure secure interaction between computers and mobile clients. Summary of the Invention

[0003] This application is made in view of at least one of the aforementioned technical problems existing in the prior art. According to one aspect of this application, a data protection method is provided, applied to a first client, the method comprising:

[0004] The first client and the second client establish a pipeline connection through the server;

[0005] The first client sends a shared data access request to the second client through the pipe connection; wherein the shared data is encrypted data;

[0006] The first client receives the first key information corresponding to the shared data sent by the second client through the pipe connection, and uses the first key information to decrypt and access the shared data.

[0007] In some embodiments, the pipe connection includes a connection between the second client and the first pipe, and a connection between the first client and the second pipe; the first pipe is used by the second client to send messages to the first client and to read messages; the second pipe is used by the first client to send messages to the second client and to read messages.

[0008] In some embodiments, the first client and the second client establish a pipeline connection through the server, including:

[0009] The first client generates a first graphic code, which enables the second client to authorize the establishment of the pipeline connection by scanning the first graphic code.

[0010] In some embodiments, the first client and the second client establish a pipeline connection through the server, including:

[0011] The first client requests a first pipe from the server and receives a universally unique identifier for the first pipe returned by the server.

[0012] The first client generates a first graphic code, which enables the second client to be authorized to log in to the first pipeline using the universally unique identifier through the first graphic code, and to write a confirmation message to the first pipeline using a first data format; wherein, the first graphic code includes the universally unique identifier and the first data format;

[0013] The first client polls and reads the confirmation message at a first preset time interval, and removes the confirmation message from the first channel within a second preset time interval; wherein, the confirmation message represents the connection status between the second client and the first channel;

[0014] The first client polls and reads connection messages at a first preset time interval to obtain authorization to use the second pipe, and removes the connection messages from the first pipe at a second preset time interval; wherein, the second pipe is requested by the second client from the server; the connection messages include a second data format, which is adopted by the first client to write messages to the second pipe;

[0015] The first client uses the second data format to write a notification that the confirmation message and the connection message have been removed into the second pipe, so that the second client can obtain the connection status between the first client and the second pipe through the notification.

[0016] In some embodiments, wherein

[0017] If the confirmation message or the connection message is not removed from the first pipeline by the first client during the second preset time interval, the confirmation message or the connection message will be re-delivered to the first pipeline by the server.

[0018] In some embodiments, the first client sends a shared data access request to the second client via the pipe connection, including:

[0019] The first client writes the shared data access request to the second pipe using the second data format, so that the second client obtains the shared data access request when polling the second pipe.

[0020] In some embodiments, the first client receives first key information corresponding to the shared data sent by the second client through the pipe connection, and uses the first key information to decrypt and access the shared data, including:

[0021] The first client polls the first pipe at a first preset time interval to receive response data sent by the second client;

[0022] The first client obtains permission to access the shared data based on the response data, and accesses the shared data based on the permission; wherein, the response data includes any one of the following: plaintext of a first key for decrypting the shared data, ciphertext obtained by encrypting the plaintext with a transmission key, key information for generating the first key, or ciphertext obtained by encrypting the key information with a transmission key;

[0023] The first client removes the response data from the first pipeline within a second preset time interval.

[0024] In some embodiments, the method further includes:

[0025] After polling the first pipeline at a first preset time interval, the first client stores the response data in its local memory.

[0026] The first client polls and reads the permission cancellation notification in the first pipeline;

[0027] The first client deletes the transmission key and / or the first key information stored in its local storage based on the notification of permission cancellation.

[0028] In some embodiments, the method further includes:

[0029] The first client obtains the token sent by the second client through the first pipe; wherein the token is applied for by the second client and is used for authentication when the first client or the second client sends a request to the server.

[0030] In some embodiments, the method further includes:

[0031] The first client sends a first heartbeat packet to the second pipeline using the second data format at a first preset time interval, and polls the first pipeline at the first preset time interval to read the second heartbeat packet sent by the second client.

[0032] In some embodiments, the method further includes:

[0033] The first client writes a notification of logging out of the second pipe to the second pipe, so that the second client can know the first client's logout status by polling the second pipe.

[0034] In some embodiments, when the first client is offline, the pipe connection is broken, the first client generates a new first graphic code, so that the second client rescans the new first graphic code to re-establish a new pipe connection; and / or,

[0035] Specifically, when the first client is online and the second client is offline, the universally unique identifier of the first pipeline and the first data format are stored locally on the second client so that the second client can maintain a pipeline connection with the first client when switching to an online state.

[0036] In some embodiments, the method further includes:

[0037] The first client generates a second graphical code, which includes a creation request, the creation request being used to request the creation of a new shared folder;

[0038] The first client polls the first pipe to obtain the second key information corresponding to the new shared folder; the second key information is written into the first pipe by the second client in response to the creation request, and the creation request is obtained by the second client by scanning the second graphic code;

[0039] The first client creates a new shared file based on the second key information.

[0040] Another aspect of this application provides a data protection method applied to a second client, the method comprising:

[0041] The second client and the first client establish a pipeline connection through the server;

[0042] The second client receives a shared data access request sent by the first client through the pipe connection; wherein the shared data is encrypted data;

[0043] The second client sends the first key information corresponding to the shared data through the pipe connection, so that the first client can use the first key information to decrypt and access the shared data.

[0044] In some embodiments, the pipe connection includes a connection between the second client and the first pipe, and a connection between the first client and the second pipe; the first pipe is used by the second client to send messages to the first client and to read messages; the second pipe is used by the first client to send messages to the second client and to read messages.

[0045] In some embodiments, the second client and the first client establish a pipeline connection through the server, including:

[0046] The second client is authorized to establish the pipeline connection by scanning the first graphic code; wherein the first graphic code is generated by the first client.

[0047] In some embodiments, the second client and the first client establish a pipeline connection through the server, including:

[0048] The second client is authorized to log in to the first pipeline using a unique identifier by scanning the first graphic code, and writes a confirmation message to the first pipeline using a first data format, so that the first client knows the connection status between the second client and the first pipeline; wherein, the first pipeline is applied for by the first client from the server, the universally unique identifier is used to log in to the first pipeline, and the first graphic code includes the universally unique identifier and the first data format; wherein, the confirmation message will be removed from the first pipeline by the first client at a second preset time interval;

[0049] The second client requests a second pipe from the server and receives the corresponding universally unique identifier for the second pipe returned by the server;

[0050] The second client writes a connection message to the first pipe using the first data format, the connection message including a second data format; wherein, the second data format is used by the first client to write a message to the second pipe, and the connection message will be removed from the first pipe by the first client at a second preset time interval;

[0051] The second client polls the second pipe to obtain a notification that the confirmation message and the connection message have been removed, and obtains the connection status between the first client and the second pipe through the notification.

[0052] In some embodiments, wherein

[0053] If the confirmation message or the connection message is not removed from the first pipeline by the first client during the second preset time interval, the confirmation message or the connection message will be re-delivered to the first pipeline by the server.

[0054] In some embodiments, the second client receives a shared data access request sent by the first client through the pipe connection, including:

[0055] The second client polls the second pipe at a first preset time interval to receive shared data access requests written by the first client in the second data format.

[0056] In some embodiments, the second client sends first key information corresponding to the shared data through the pipe connection, so that the first client can use the first key information to decrypt and access the shared data, including:

[0057] The second client generates response data based on the shared data access request; wherein the response data includes any one of the following: plaintext of the first key used to decrypt the shared data, ciphertext obtained by encrypting the plaintext with a transmission key, key information used to generate the first key, or ciphertext obtained by encrypting the key information with a transmission key;

[0058] The second client writes the response data into the first pipe in a second data format, so that the first client can obtain permission to access the shared data based on the response data; wherein, the response data in the first pipe will be removed by the first client within a second preset time interval.

[0059] In some embodiments, the method further includes:

[0060] The second client writes a notification to revoke permissions to the first pipe, so that the first client deletes the transmission key and / or the first key information stored in local storage based on the notification to revoke permissions.

[0061] In some embodiments, the method further includes:

[0062] The second client requests and obtains a token from the server;

[0063] The second client writes the token into the first pipe so that the first client obtains the token; wherein the token is used for authentication when the first client or the second client sends a request to the server.

[0064] In some embodiments, the method further includes:

[0065] The second client sends a first heartbeat packet to the first pipeline using the first data format at a first preset time interval, and polls the second pipeline at the first preset time interval to read the second heartbeat packet sent by the first client.

[0066] In some embodiments, the second client polls and reads the second pipe to obtain a notification that the first client has logged out, as well as the first client's logout status.

[0067] In some embodiments, when the first client is offline, the pipe connection is broken, and the second client re-establishes a new pipe connection by scanning a new first graphic code generated by the first client; and / or,

[0068] When the second client is offline and the first client is online, the second client maintains a pipeline connection with the first client by using the universally unique identifier of the first pipeline and the first data format that are pre-stored locally when switching to the online state.

[0069] In some embodiments, the method further includes:

[0070] The second client creates a new shared folder and a second key information for the new shared folder on the server according to the instruction to create a new shared folder.

[0071] In some embodiments, the second client obtains a request to create a new shared folder by scanning a second graphic code;

[0072] In response to the request to create a new shared folder, the second client writes the second key information corresponding to the new shared folder into the first pipe, so that the first client creates a new shared file based on the second key information.

[0073] In another aspect, this application provides a terminal, the terminal comprising:

[0074] A memory and a processor, wherein the memory stores a computer program that is executed by the processor, and the computer program, when executed by the processor, causes the processor to perform the data protection method as described above.

[0075] Another embodiment of this application provides a data protection system, the system including a first client, a second client, and a server; wherein...

[0076] The first client is configured to establish a pipe connection with the second client through the server, and send a shared data access request to the second client through the pipe connection, and receive the first key information corresponding to the shared data sent by the second client through the pipe connection, and decrypt and access the shared data using the first key information; wherein, the shared data is encrypted data;

[0077] The second client is configured to establish a pipeline connection with the first client through the server, and receive the shared data access request sent by the first client through the pipeline connection; and send the first key information corresponding to the shared data through the pipeline connection, so that the first client can use the first key information to decrypt and access the shared data;

[0078] The server is configured to issue a universally unique identifier for the first pipeline and a universally unique identifier for the second pipeline to the first client and the second client respectively, based on the pipeline creation requests from the first client and the second client, so that the first client and the second client can establish a pipeline connection.

[0079] The server is also configured to receive data access requests from the first client and / or the second client, and to authenticate the first client and / or the second client based on the token carried in the data access request.

[0080] In another aspect, this application provides a storage medium storing a computer program that, when run by a processor, causes the processor to perform the data protection method described above.

[0081] In another aspect, this application provides a computer program product that, when executed by a processor, implements the data protection method described above.

[0082] In this embodiment of the application, during the process of controlling the first client's access to shared data through the second client, the messages are transmitted through a pipe connection and are not recorded in the caches of each terminal (the client is installed on the terminal). This ensures that the messages cannot be eavesdropped on or tampered with, and guarantees the communication security between the first client and the second client. Attached Figure Description

[0083] Figure 1 A schematic flowchart illustrating a data protection method according to an embodiment of this application is shown;

[0084] Figure 2 A schematic flowchart illustrating step S101 according to an embodiment of this application is shown;

[0085] Figure 3 A schematic flowchart illustrating step S101 according to another embodiment of this application is shown;

[0086] Figure 4 A schematic flowchart illustrating step S102 according to an embodiment of this application is shown;

[0087] Figure 5 A schematic flowchart illustrating step S103 according to an embodiment of this application is shown;

[0088] Figure 6 A schematic flowchart illustrating the cancellation of a first client's access permission to shared data according to an embodiment of this application is shown.

[0089] Figure 7 A schematic flowchart illustrating a first pipeline for obtaining a token according to an embodiment of this application is shown;

[0090] Figure 8 A schematic flowchart illustrating the sending of heartbeat packets between a first client and a second client at a first preset time interval according to an embodiment of this application is shown.

[0091] Figure 9 This diagram illustrates a schematic flowchart of a first client logging out according to an embodiment of this application.

[0092] Figure 10 A schematic flowchart illustrating the creation of a new shared folder for a first client according to an embodiment of this application is shown;

[0093] Figure 11 A schematic flowchart illustrating a second client authorizing a first client to create a new shared folder according to an embodiment of this application is shown.

[0094] Figure 12 This diagram illustrates how a first client and a second client interact via a server-side pipeline connection according to an embodiment of this application.

[0095] Figure 13 This diagram illustrates a schematic block diagram of a data protection system according to an embodiment of this application;

[0096] Figure 14 A schematic block diagram of a terminal according to an embodiment of this application is shown. Detailed Implementation

[0097] To enable those skilled in the art to better understand the technical solutions of the embodiments of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0098] To address at least one of the aforementioned technical problems, this application provides a data protection method applied to a first client. The method includes: establishing a pipeline connection between the first client and a second client through a server; the first client sending a shared data access request to the second client through the pipeline connection; wherein the shared data is encrypted data; the first client receiving first key information corresponding to the shared data sent by the second client through the pipeline connection, and using the first key information to decrypt and access the shared data.

[0099] This application also provides a data protection method applied to a second client. The method includes: the second client and a first client establishing a pipe connection through a server; the second client receiving a shared data access request sent by the first client through the pipe connection; wherein the shared data is encrypted data; and the second client sending first key information corresponding to the shared data through the pipe connection, so that the first client can use the first key information to decrypt and access the shared data.

[0100] In this embodiment, the second client controls the first client's access to shared data. During this process, messages are transmitted through a pipe connection and are not recorded in the caches of each terminal (where the client is installed). This ensures that messages cannot be eavesdropped on or tampered with, guarantees the communication security between the first and second clients, and improves the security of shared data when accessed by the first client.

[0101] Figure 1 A schematic flowchart illustrating a data protection method according to an embodiment of this application is shown; Figure 12 This diagram illustrates how a first client and a second client interact via a server-side pipeline connection according to an embodiment of this application. Figure 1 and Figure 12 As shown, the data protection method 100 according to an embodiment of this application may include the following steps S101, S102 and S103:

[0102] In step S101, the first client and the second client establish a pipeline connection through the server.

[0103] The pipeline connection includes the connection between the second client and the first pipeline, and the connection between the first client and the second pipeline; the first pipeline is used by the second client to send messages to the first client and to read messages; the second pipeline is used by the first client to send messages to the second client and to read messages.

[0104] For example, the first client is installed on terminals such as personal computers (PCs), laptops, smartphones, tablets, and smartwatches, while the second client is installed on mobile terminals such as smartphones, tablets, smartwatches, and computers (PCs), laptops, etc. For example, the first client is the PC application MiKey (a platform software product that provides users with functions such as secure data sharing), and the second client is the mobile application MiKey.

[0105] This application uses an example of a first client installed on a computer (PC) and a second client installed on a smartphone to illustrate the technical solution of this application.

[0106] The server in this embodiment is configured with pipeline logic. After the first client and the second client establish a pipeline connection through the server, the two clients can use the server's pipeline logic to send messages to each other for communication, thereby performing implicit information exchange and ensuring the security of the interaction between the first client and the second client.

[0107] In one embodiment of this application, such as Figure 2 As shown, in step S101, the first client and the second client establish a pipeline connection through the server, including step S201:

[0108] In step S201, the first client generates a first graphic code, so that the second client can authorize the establishment of the pipeline connection by scanning the first graphic code.

[0109] For example, the first graphic code may include one-dimensional barcodes, two-dimensional barcodes (also known as QR codes), three-dimensional codes, and other graphic codes.

[0110] In one example, such as Figure 3 As shown, in step S101, the first client and the second client establish a pipeline connection through the server, including steps S301, S302, S303, S304, and S305:

[0111] Step S301: The first client requests a first pipe from the server and receives a universally unique identifier for the first pipe returned by the server.

[0112] Step S302: The first client generates a first graphic code so that the second client is authorized to log in to the first pipeline using the universally unique identifier through the first graphic code, and writes a confirmation message to the first pipeline using a first data format; wherein, the first graphic code includes the universally unique identifier and the first data format;

[0113] Step S303: The first client polls and reads the confirmation message at a first preset time interval, and removes the confirmation message from the first channel within a second preset time interval; wherein, the confirmation message represents the connection status between the second client and the first channel;

[0114] Step S304: The first client polls and reads connection messages at a first preset time interval to obtain authorization to use the second pipe, and removes the connection messages from the first pipe at a second preset time interval; wherein, the second pipe is requested by the second client from the server; the connection messages include a second data format, which is adopted by the first client to write messages to the second pipe;

[0115] In step S305, the first client uses the second data format to write a notification that the confirmation message and the connection message have been removed into the second pipe, so that the second client can obtain the connection status between the first client and the second pipe through the notification.

[0116] If the confirmation message or connection message is not removed from the first pipeline by the first client during the second preset time interval, the confirmation message or connection message will be re-delivered to the first pipeline by the server.

[0117] Meanwhile, after logging in, the first client installed on the computer (PC) and the second client installed on the smartphone can complete the display interaction. That is to say, any access and / or read / write operations performed by the first client on shared data will be displayed on the second client's interface.

[0118] In one example, the process of establishing a pipeline connection between the first client and the second client is as follows:

[0119] The first step is for the first client to request the first pipeline from the server, and the server returns a universally unique identifier (UUID) for the first pipeline.

[0120] The second step involves the first client generating a QR code, which the second client scans to obtain the first data format. The first data format can be defined by the first client according to its specific needs.

[0121] For example, the first data format is as follows:

[0122] platform from type, client version, pipeline uuid, random (8 bytes base64) eg: "2,1,6ab01a5a-4412-4ae8-b67e-59a9ed1c9e01,MTIzNDU2Nzg=".

[0123] The information in the QR code, after being compiled, yields the following code:

[0124]

[0125]

[0126] The "platform type" can represent the system type on either the computer or mobile device. For example, the system type can be any of the following: Microsoft Windows, Android, Apple iOS, macOS, or Linux. If both parties agree that 0 represents an unknown system, 1 represents Android, 2 represents iOS, 3 represents macOS, 4 represents Windows, and 5 represents Linux, then the number 2 in the above message indicates that the first client's system type is iOS.

[0127] The client version can be the version information of the first client. For example, if the version information in the above message is 1, and if it is agreed that 1 represents version information 0x102, then the version information of the first client mentioned above is 0x102.

[0128] The pipeline UUID can represent the universally unique identifier (UUID) of the first pipeline. For example, the universally unique identifier (UUID) obtained after compiling the above message is 389a9361-8160-4391-82f5-d59fa9ef307a.

[0129] `random` can represent a random number. For example, the random number for the message above is `MTIzNDU2Nzg`.

[0130] Third, the second client scans the QR code to obtain the first data format, and then uses the first data format to write a confirmation message to the first client's first pipeline. For example, the confirmation message is:

[0131] {protocol:1

[0132] type:1

[0133] status:0 / / 0, QR code scan successful, awaiting confirmation; 1, login denied.

[0134] In this message, `protocol` represents the protocol version number, and `status` represents the login status. A value of 0 for `status` indicates successful QR code scanning and awaiting confirmation; a value of 1 indicates login was rejected. In the above message, a `status` of 0 indicates that the second client successfully scanned the QR code and is awaiting confirmation from the first client.

[0135] Fourth, the first client polls the first pipeline to obtain a confirmation message and login status. The first client removes the confirmation message from the first pipeline within 30 seconds.

[0136] In one example, if a message in the pipe is not read for a long time, the client may fail to read the message. To prevent this and ensure the reliability of communication between the two parties, the server can resend the message to the pipe.

[0137] The client can continuously write messages to the pipeline. Since both the first and second pipelines are stored in the server's memory, and server memory has limited storage space, storing too many messages can put pressure on the server's runtime, potentially causing message congestion. Therefore, to reduce the pressure on the server's runtime, the client can remove messages after a certain period of time following their writing. After removing a message, the client writes a notification of message removal to the other pipeline, so that the other pipeline is aware that the message has been read. This message reading interval can be set according to actual needs; for example, 30 seconds.

[0138] Clearly, since the time interval for reading messages is also the time interval for each polling cycle, this time interval should be shorter than the time interval for removing messages. For example, the polling interval could be 5 seconds, and the message removal interval could be 30 seconds. This ensures that the client reads messages and removes them promptly, reducing the storage pressure on the server.

[0139] For example, the first client can confirm by removing the message from the first pipeline and writing the removal notification to the second pipeline. After the second client reads the removal notification from the second pipeline, it indicates that the first client has confirmed the connection and the pipeline connection between the two parties is successful.

[0140] In addition, the first and second pipelines mentioned above can be stored in the server's memory, so that the first client and the second client can interact with each other through the server's pipelines, ensuring the security of the interacting information.

[0141] Accordingly, when the second client establishes a pipeline connection with the first client through the server, the connection process may include:

[0142] The first step is for the second client to request a second pipeline from the server and receive a Universally Unique Identifier (UUID) for the second pipeline returned by the server.

[0143] The second step involves the second client assembling data in a second format, which is then adopted by the first client to write messages to the second pipe. This second data format includes the universally unique identifier (UUID) information for the second pipe.

[0144] Third, the second client uses the transmission key to encrypt the plaintext of the first key for sharing data to obtain the ciphertext of the plaintext. For example, the transmission key is used to generate the ciphertext using the pbkdf2 algorithm with random.

[0145] Fourth, the second client writes an acknowledgment message to the first pipeline. This acknowledgment message may contain a second data format, allowing the first client to use this format to write messages to the second pipeline. This signifies that the first client has been authorized to use the second pipeline.

[0146] In step S102, the first client sends a shared data access request to the second client through the pipe connection.

[0147] The shared data is encrypted.

[0148] For example, shared data can include shared folders and shared files.

[0149] In one embodiment of this application, such as Figure 4 As shown, in step S102, the first client sends a shared data access request to the second client through the pipe connection, including step S401:

[0150] In step S401, the first client writes the shared data access request to the second pipe using the second data format, so that the second client obtains the shared data access request when polling the second pipe.

[0151] In step S103, the first client receives the first key information corresponding to the shared data sent by the second client through the pipe connection, and uses the first key information to decrypt and access the shared data.

[0152] In the above message, "secrets" refers to the keys for different file directories. The first client can decrypt and view the files corresponding to the keys provided by the second client.

[0153] In this embodiment, the second client has access to all shared data within the current user's permission scope, and can obtain access to all shared data, thus enabling the second client to control the access permissions of the first client. This method refines the second client's management function of shared data access permissions to the first client, and also ensures message security during interaction between the first and second clients, as all messages are exchanged internally on the server side.

[0154] In one embodiment of this application, such as Figure 5 As shown, in step S103, the first client receives the first key information corresponding to the shared data sent by the second client through the pipe connection, and uses the first key information to decrypt and access the shared data, including steps S501, S502, and S503:

[0155] In step S501, the first client polls the first pipe at a first preset time interval to receive response data sent by the second client;

[0156] In step S502, the first client obtains permission to access the shared data based on the response data, and accesses the shared data based on the permission.

[0157] In step S503, the first client removes the response data from the first pipeline within a second preset time interval.

[0158] The response data includes any one of the following: plaintext of a first key used to decrypt shared data, ciphertext obtained by encrypting the plaintext with a transmission key, key information used to generate the first key, or ciphertext obtained by encrypting the key information with a transmission key.

[0159] In other words, the response data can contain multiple implementations of the first key information. The implementations of the first key information include at least one of the following:

[0160] (1) The plaintext of the first key used to decrypt the shared data. At this point, the shared data is the data encrypted with the first key.

[0161] (2) The ciphertext obtained by encrypting the plaintext of the first key with the transmission key.

[0162] (3) Some key information used to generate the first key. The first client can calculate the first key based on this key information and then decrypt the shared data.

[0163] (4) The ciphertext obtained by encrypting the key information with the transmission key.

[0164] In one embodiment of this application, such as Figure 6 The diagram shown is a schematic flowchart for canceling the first client's access permission to shared data. The method further includes steps S601, S602, and S603:

[0165] In step S601, after the first client polls the first pipe at a first preset time interval, it stores the response data in its local memory.

[0166] In step S602, the first client polls and reads the notification of permission cancellation in the first pipeline;

[0167] In step S603, the first client deletes the transmission key and / or the first key information stored in the local storage based on the notification of permission cancellation.

[0168] In this embodiment, when the first client revokes access permission to a folder, the second client writes a notification of permission revocation to the first channel. Based on this notification, the first client deletes the transmission key and / or the first key information stored in its local memory. For example, if the second client writes ciphertext encrypted with the transmission key to the first client's first channel, the first client deletes the ciphertext it previously stored in its local memory. This method eliminates the need for multiple information exchanges and is relatively simple to implement.

[0169] In one embodiment of this application, such as Figure 7 The diagram shown is a schematic flowchart of the first pipeline for obtaining a token. The method further includes step S701:

[0170] In step S701, the first client obtains the token sent by the second client through the first pipe; wherein the token is requested by the second client from the server and is used for authentication when the first client or the second client sends a request to the server.

[0171] In this embodiment, the token is requested by the second client from the server. The token can be used to verify the identity information of the client (including the first client and the second client) when sending a request to the server. When the client (including the first client and the second client) sends a request to the server, the token can be placed in the header information of the request.

[0172] After requesting a token from the server, the second client can send the token to the first client via a pipe connection. In one example, the token can be sent to the first client as part of the connection message, or it can be written as a separate message to the first pipe, enabling the first client to obtain the token.

[0173] In this embodiment, the first client and the second client share a single token. When the second client logs out, the first client's token also becomes invalid, and the first client also logs out. This ensures the second client's absolute control over the first client's server access permissions. In other words, when the second client logs out, its token becomes invalid, and the first client's token also becomes invalid. Because the first client loses its token, it no longer has the permission to access the server's shared data and therefore cannot access it. Only when the second client logs in and its token is valid can the first client access the server's shared data, thus achieving absolute control of the second client's server access permissions over the first client.

[0174] In one embodiment of this application, such as Figure 8 The diagram illustrates a schematic flowchart of the first client and the second client sending heartbeat packets at a first preset time interval. The method further includes step S801:

[0175] In step S801, the first client sends a first heartbeat packet to the second pipe using the second data format at a first preset time interval, and polls the first pipe at the first preset time interval to read the second heartbeat packet sent by the second client.

[0176] In this embodiment, the first client and the second client need to maintain heartbeats to ensure uninterrupted communication. In one example, the first and second clients can use timers to poll the messages in their respective pipelines; for example, every 5 seconds, the first and second clients poll their own pipelines. This heartbeat and timed polling method ensures good real-time performance between the first and second clients.

[0177] In one embodiment of this application, such as Figure 9 The diagram shown illustrates the process of a first client logging out. The method further includes step S901:

[0178] In step S901, the first client writes a notification of logging out of the second pipe into the second pipe, so that the second client can know the logout status of the first client by polling the second pipe.

[0179] In one embodiment of this application, when the first client is offline, the pipeline connection is disconnected, and the first client generates a new first graphic code so that the second client rescans the new first graphic code to re-establish a new pipeline connection.

[0180] In another embodiment of this application, when the first client is online and the second client is offline, the universally unique identifier of the first pipeline and the first data format are stored locally on the second client so that the second client can maintain a pipeline connection with the first client when switching to an online state.

[0181] For example, when the first client polls the first pipe, it reads the transmission key written by the second client and stores it in its local memory. When the first client is offline and then returns to online, it re-requests the first pipe and generates a first graphical code containing the first pipe's UUID and a first data format. The second client then rescans the first graphical code to obtain authorization to log in to the new first pipe. This ensures the second client's permission to access the shared folder from the first client, while also guaranteeing the security of interactions between the second and first clients.

[0182] In one embodiment of this application, such as Figure 10 The diagram shown is a schematic flowchart of the process of creating a new shared folder by the first client. The method further includes steps S1001, S1002, and S1003:

[0183] In step S1001, the first client generates a second graphical code, which includes a creation request for requesting the creation of a new shared folder.

[0184] In step S1002, the first client polls the first pipe to obtain the second key information corresponding to the new shared folder; the second key information is written into the first pipe by the second client in response to the creation request, and the creation request is obtained by the second client by scanning the second graphic code;

[0185] In step S1003, the first client creates a new shared file based on the second key information.

[0186] In this embodiment, the permissions for creating new shared files differ between the first client and the second client. When the first client needs to create a new shared folder, it requires authorization from the second client. However, the second client can create a new shared folder directly on the server without obtaining authorization from other clients.

[0187] In one embodiment of this application, such as Figure 11 The diagram shown illustrates a schematic flowchart of a second client authorizing a first client to create a new shared folder. The method further includes steps S1101 and S1102:

[0188] In step S1101, the second client obtains a request to create a new shared folder by scanning the second graphic code;

[0189] In step S1102, in response to the request to create a new shared folder, the second client writes the second key information corresponding to the new shared folder into the first pipe, so that the first client creates a new shared file based on the second key information.

[0190] Additionally, in one example, the first client can generate a third data format. This allows the second client to write a response to the request to create a new shared folder to the first pipeline using the third data format, distinguishing it from a different type of message written using the first data format.

[0191] For example, when the first client creates a new shared folder, it first needs to assemble its own information, which may include information such as the name of the new shared folder. Then, the first client generates a second graphic code (e.g., a one-dimensional, two-dimensional, or three-dimensional barcode), which contains a request to create the new shared folder and may also contain a third data format. The second client obtains the request from the first client to create the new shared folder by scanning the second graphic code. After generating second key information for the new shared folder, the second client transmits the second key information to the first client's first pipeline. The first client polls the pipeline, and once it obtains the second key information, it can proceed with the operation of creating the new shared folder.

[0192] The second key information may include at least one of the following:

[0193] (1) Plaintext of the second key used to decrypt the new shared folder. At this point, the shared data is a shared folder encrypted with the second key.

[0194] (2) The ciphertext obtained by encrypting the plaintext of the second key with the transmission key.

[0195] (3) Some key information used to generate the second key. The first client can calculate the second key based on this key information and then decrypt the shared data folder.

[0196] (4) The ciphertext obtained by encrypting the key information with the transmission key.

[0197] When a second client needs to create a new shared folder, it can do so directly on the server without obtaining authorization from other clients. For example, the second client creates a new shared folder and its second key information on the server according to the instruction to create a new shared folder. When the first client sends a request to access the new shared folder via a piped connection, the second client can send the second key information corresponding to the new shared folder to the first piped connection, allowing the first client to access the new shared folder based on the second key information.

[0198] In this embodiment of the application, during the process of controlling the first client's access to shared data through the second client, the messages are transmitted through a pipe connection and are not recorded in the caches of each terminal (the client is installed on the terminal). This ensures that the messages cannot be eavesdropped on or tampered with, and guarantees the communication security between the first client and the second client.

[0199] This application also provides a data protection system, such as... Figure 13As shown, the data protection system 1300 includes a first client 1301, a second client 1302, and a server 1303. Among them,

[0200] The first client 1301 is configured to establish a pipe connection with the second client through a server, and send a shared data access request to the second client through the pipe connection, and receive the first key information corresponding to the shared data sent by the second client through the pipe connection, and decrypt and access the shared data using the first key information; wherein, the shared data is encrypted data;

[0201] The second client 1302 is used to establish a pipeline connection with the first client through the server, and to receive the shared data access request sent by the first client through the pipeline connection; and to send the first key information corresponding to the shared data through the pipeline connection, so that the first client can use the first key information to decrypt and access the shared data;

[0202] The server 1303 is used to send a universally unique identifier for the first pipe and a universally unique identifier for the second pipe to the first client and the second client respectively, based on the pipe creation requests from the first client and the second client, so that the first client and the second client can establish a pipe connection.

[0203] The server 1303 is further configured to receive data access requests from the first client and / or the second client, and to authenticate the first client and / or the second client based on the token carried in the data access request.

[0204] The various pipes in this application embodiment are independent of each other. The disconnection or delay of any one pipe will not affect the other pipes, thereby ensuring the stability of the entire system.

[0205] The following is combined Figure 14 The terminal of this application is described, wherein, Figure 14 A schematic block diagram of a terminal according to an embodiment of this application is shown.

[0206] like Figure 14 As shown, terminal 1400 includes: one or more memories 1401 and one or more processors 1402. The memories 1401 store a computer program that is executed by the processors 1402. When the computer program is executed by the processors 1402, the processors 1402 perform the power device layout design method described above.

[0207] Terminal 1400 may be part or all of a computer device that can implement a power device layout design method through software, hardware, or a combination of software and hardware.

[0208] like Figure 14 As shown, terminal 1400 includes one or more memories 1401, one or more processors 1402, a display (not shown), and a communication interface, etc., which are interconnected via a bus system and / or other forms of connection mechanisms (not shown). It should be noted that... Figure 14 The components and structure of the terminal 1400 shown are merely exemplary and not limiting. The terminal 1400 may also have other components and structures as needed.

[0209] Memory 1401 is used to store various data and executable program instructions generated during train operation, such as algorithms for storing various applications or implementing various specific functions. It may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0210] The processor 1402 may be a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other processing units with data processing capabilities and / or instruction execution capabilities, and may be other components in the terminal 1400 to perform the desired functions.

[0211] In one example, terminal 1400 also includes an output device that can output various information (such as images or sounds) to the outside (e.g., a user), and may include one or more of a display device, a speaker, etc.

[0212] The communication interface can be any known communication protocol interface, such as a wired interface or a wireless interface. The communication interface may include one or more serial ports, USB interfaces, Ethernet ports, WiFi, wired networks, DVI interfaces, device integrated interconnect modules, or other suitable ports, interfaces, or connections.

[0213] Furthermore, according to embodiments of this application, a storage medium is also provided, on which program instructions are stored. When executed by a computer or processor, these program instructions are used to perform corresponding steps of the power device layout design method of embodiments of this application. The storage medium may, for example, include a memory card for a smartphone, a storage component for a tablet computer, a hard disk for a personal computer, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a portable compact disc read-only memory (CD-ROM), a USB memory, or any combination of the above storage media.

[0214] This application also provides a computer program product, which, when executed by a processor, implements the data protection method described above.

[0215] The data protection system, terminal, storage medium, and computer program product of this application embodiment have the same advantages as the aforementioned data protection method because they can implement the aforementioned data protection method.

[0216] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of this application. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of this application. All such changes and modifications are intended to be included within the scope of this application as claimed in the appended claims.

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

[0218] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0219] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0220] Similarly, it should be understood that, in order to streamline this application and aid in understanding one or more of the various inventive aspects, features of this application may sometimes be grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of this application. However, this approach should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with features fewer than all features of a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0221] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or apparatus so disclosed can be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0222] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any one of the claimed embodiments can be used in any combination.

[0223] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules according to the embodiments of this application. This application can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0224] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0225] The above description is merely a specific embodiment or illustration of the embodiments of this application. The scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. The scope of protection of this application shall be determined by the scope of the claims.

Claims

1. A data protection method, characterized in that, Applied to a first client, the method includes: The first client and the second client establish a pipeline connection through the server; wherein, the pipeline connection is established by the second client by scanning the first graphic code generated by the first client, the pipeline can be used by the second client to control the first client's access to shared data, and the pipeline is stored in the memory of the server; The first client sends a shared data access request to the second client through the pipe connection; wherein the shared data is encrypted data that the second client has access to. The first client receives the first key information corresponding to the shared data sent by the second client through the pipe connection, so as to obtain the permission to access the shared data granted by the second client; The first client uses the first key information to decrypt and access the shared data; When the first client receives a notification from the second client to revoke permission via the pipe connection, it deletes the first key information stored in its local storage. Specifically, when the first client is offline, the pipeline connection is broken, and the first client generates a new first graphic code so that the second client can rescan the new first graphic code to re-establish a new pipeline connection; and when the first client is online and the second client is offline, the universal unique identifier and first data format of the first pipeline in the pipeline are stored locally on the second client so that the second client can maintain the pipeline connection with the first client when switching to an online state.

2. The method according to claim 1, characterized in that, The pipeline connection includes the connection between the second client and the first pipeline, and the connection between the first client and the second pipeline; the first pipeline is used by the second client to send messages to the first client and to read messages; the second pipeline is used by the first client to send messages to the second client and to read messages.

3. The method according to any one of claims 1 to 2, characterized in that, The first client and the second client establish a pipeline connection through the server, including: The first client requests a first pipe from the server and receives a universally unique identifier for the first pipe returned by the server. The first client generates a first graphic code, which enables the second client to be authorized to log in to the first pipeline using the universally unique identifier through the first graphic code, and to write a confirmation message to the first pipeline using a first data format; wherein, the first graphic code includes the universally unique identifier and the first data format; The first client polls and reads the confirmation message at a first preset time interval, and removes the confirmation message from the first channel within a second preset time interval; wherein, the confirmation message represents the connection status between the second client and the first channel; The first client polls and reads connection messages at a first preset time interval to obtain authorization to use the second pipe, and removes the connection messages from the first pipe at a second preset time interval; wherein, the second pipe is requested by the second client from the server; the connection messages include a second data format, which is adopted by the first client to write messages to the second pipe; The first client uses the second data format to write a notification that the confirmation message and the connection message have been removed into the second pipe, so that the second client can obtain the connection status between the first client and the second pipe through the notification.

4. The method according to claim 3, characterized in that, in, If the confirmation message or the connection message is not removed from the first pipeline by the first client during the second preset time interval, the confirmation message or the connection message will be re-delivered to the first pipeline by the server.

5. The method according to claim 2, characterized in that, The first client sends a shared data access request to the second client through the pipe connection, including: The first client writes the shared data access request to the second pipe using the second data format, so that the second client obtains the shared data access request when polling the second pipe.

6. The method according to claim 2, characterized in that, The first client receives the first key information corresponding to the shared data sent by the second client through the pipe connection, and uses the first key information to decrypt and access the shared data, including: The first client polls the first pipe at a first preset time interval to receive response data sent by the second client; The first client obtains permission to access the shared data based on the response data, and accesses the shared data based on the permission; wherein, the response data includes any one of the following: plaintext of a first key for decrypting the shared data, ciphertext obtained by encrypting the plaintext with a transmission key, key information for generating the first key, or ciphertext obtained by encrypting the key information with a transmission key; The first client removes the response data from the first pipeline within a second preset time interval.

7. The method according to claim 6, characterized in that, The method further includes: After polling the first pipeline at a first preset time interval, the first client stores the response data in its local memory. The first client polls and reads the permission cancellation notification in the first pipeline; The first client deletes the transmission key and / or the first key information stored in its local storage based on the notification of permission cancellation.

8. The method according to claim 2, characterized in that, The method further includes: The first client obtains the token sent by the second client through the first pipe; wherein the token is applied for by the second client and is used for authentication when the first client or the second client sends a request to the server.

9. The method according to claim 3, characterized in that, The method further includes: The first client sends a first heartbeat packet to the second pipeline using the second data format at a first preset time interval, and polls the first pipeline at the first preset time interval to read the second heartbeat packet sent by the second client.

10. The method according to claim 1, characterized in that, The method further includes: The first client writes a notification of logging out of the second pipeline into the second pipeline, so that the second client can know the first client's logout status by polling the second pipeline.

11. The method according to claim 1 or 2, characterized in that, The method further includes: The first client generates a second graphical code, which includes a creation request, the creation request being used to request the creation of a new shared folder; The first client polls the first pipe to obtain the second key information corresponding to the new shared folder; the second key information is written into the first pipe by the second client in response to the creation request, and the creation request is obtained by the second client by scanning the second graphic code; The first client creates a new shared file based on the second key information.

12. A data protection method, characterized in that, Applied to a second client, the method includes: The second client and the first client establish a pipeline connection through the server; wherein, the pipeline connection is established by the second client by scanning the first graphic code generated by the first client, the pipeline can be used by the second client to control the first client's access to shared data, and the pipeline is stored in the memory of the server; The second client receives a shared data access request sent by the first client through the pipe connection; wherein, the shared data is encrypted data that the second client has access to. The second client sends the first key information corresponding to the shared data through the pipe connection, so that the first client can use the first key information to decrypt and access the shared data; The second client writes a notification to cancel permissions into the pipe connection, so that the first client deletes the first key information stored in local storage based on the notification to cancel permissions; Specifically, when the first client is offline, the pipeline connection is broken, and the first client generates a new first graphic code so that the second client can rescan the new first graphic code to re-establish a new pipeline connection; and when the first client is online and the second client is offline, the universal unique identifier and first data format of the first pipeline in the pipeline are stored locally on the second client so that the second client can maintain the pipeline connection with the first client when switching to an online state.

13. The method according to claim 12, characterized in that, The pipeline connection includes the connection between the second client and the first pipeline, and the connection between the first client and the second pipeline; the first pipeline is used by the second client to send messages to the first client and to read messages; the second pipeline is used by the first client to send messages to the second client and to read messages.

14. The method according to any one of claims 12 to 13, characterized in that, The second client and the first client establish a pipeline connection through the server, including: The second client is authorized to log in to the first pipeline using a unique identifier by scanning the first graphic code, and writes a confirmation message to the first pipeline using a first data format, so that the first client knows the connection status between the second client and the first pipeline; wherein, the first pipeline is applied for by the first client from the server, the universally unique identifier is used to log in to the first pipeline, and the first graphic code includes the universally unique identifier and the first data format; wherein, the confirmation message will be removed from the first pipeline by the first client at a second preset time interval; The second client requests a second pipe from the server and receives the corresponding universally unique identifier for the second pipe returned by the server; The second client writes a connection message to the first pipe using the first data format, the connection message including a second data format; wherein, the second data format is used by the first client to write a message to the second pipe, and the connection message will be removed from the first pipe by the first client at a second preset time interval; The second client polls the second pipe to obtain a notification that the confirmation message and the connection message have been removed, and obtains the connection status between the first client and the second pipe through the notification.

15. The method according to claim 14, characterized in that, in, If the confirmation message or the connection message is not removed from the first pipeline by the first client during the second preset time interval, the confirmation message or the connection message will be re-delivered to the first pipeline by the server.

16. The method according to claim 12, characterized in that, The second client receives a shared data access request sent by the first client through the pipe connection, including: The second client polls the second pipe at a first preset time interval to receive shared data access requests written by the first client in a second data format.

17. The method according to claim 12, characterized in that, The second client sends the first key information corresponding to the shared data through the pipe connection, so that the first client can use the first key information to decrypt and access the shared data, including: The second client generates response data based on the shared data access request; wherein the response data includes any one of the following: plaintext of the first key used to decrypt the shared data, ciphertext obtained by encrypting the plaintext with a transmission key, key information used to generate the first key, or ciphertext obtained by encrypting the key information with a transmission key; The second client writes the response data into the first pipe in a second data format, so that the first client can obtain permission to access the shared data based on the response data; wherein, the response data in the first pipe will be removed by the first client within a second preset time interval.

18. The method according to claim 17, characterized in that, The method further includes: The second client writes a notification to revoke permissions to the first pipe, so that the first client deletes the transmission key and / or the first key information stored in local storage based on the notification to revoke permissions.

19. The method according to claim 12, characterized in that, The method further includes: The second client requests and obtains a token from the server; The second client writes the token into the first pipe so that the first client obtains the token; wherein the token is used for authentication when the first client or the second client sends a request to the server.

20. The method according to claim 14, characterized in that, The method further includes: The second client sends a first heartbeat packet to the first pipeline using the first data format at a first preset time interval, and polls the second pipeline at the first preset time interval to read the second heartbeat packet sent by the first client.

21. The method according to claim 12, characterized in that, The second client polls and reads the second pipe to obtain the notification that the first client has logged out, as well as the logout status of the first client.

22. The method according to any one of claims 12 to 13, characterized in that, The method further includes: The second client creates a new shared folder and a second key information for the new shared folder on the server according to the instruction to create a new shared folder.

23. The method according to any one of claims 12 to 13, characterized in that, The second client obtains a request to create a new shared folder by scanning the second graphic code; In response to the request to create a new shared folder, the second client writes the second key information corresponding to the new shared folder into the first pipe, so that the first client creates a new shared file based on the second key information.

24. A terminal, characterized in that, The terminal includes: A memory and a processor, wherein the memory stores a computer program that is executed by the processor, the computer program, when executed by the processor, causes the processor to perform the data protection method as described in any one of claims 1 to 11 or the data protection method as described in any one of claims 12 to 23.

25. A data protection system, characterized in that, The system includes a first client, a second client, and a server; wherein... The first client is configured to establish a pipeline connection with the second client through the server, and send a shared data access request to the second client through the pipeline connection, and receive first key information corresponding to the shared data sent by the second client through the pipeline connection to obtain the permission to access the shared data granted by the second client; and decrypt and access the shared data using the first key information; and delete the first key information stored in local storage when receiving a notification from the second client to cancel the permission through the pipeline connection; wherein the shared data is encrypted data that the second client has access to, the pipeline is stored in the memory of the server, the pipeline connection is established by the second client by scanning the first graphic code generated by the first client, and the pipeline can be used by the second client to control the first client's permission to access the shared data; The second client is configured to establish a pipeline connection with the first client through the server, and receive the shared data access request sent by the first client through the pipeline connection; and send the first key information corresponding to the shared data through the pipeline connection, so that the first client can use the first key information to decrypt and access the shared data; The server is configured to issue a universally unique identifier for the first pipeline and a universally unique identifier for the second pipeline to the first client and the second client respectively, based on the pipeline creation requests from the first client and the second client, so that the first client and the second client can establish a pipeline connection. The server is also configured to receive data access requests from the first client and / or the second client, and to authenticate the first client and / or the second client based on the token carried in the data access request; Specifically, when the first client is offline, the pipeline connection is broken, and the first client generates a new first graphic code so that the second client can rescan the new first graphic code to re-establish a new pipeline connection; and when the first client is online and the second client is offline, the universal unique identifier and first data format of the first pipeline in the pipeline are stored locally on the second client so that the second client can maintain the pipeline connection with the first client when switching to an online state.

26. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, causes the processor to perform the data protection method as described in any one of claims 1 to 11 or the data protection method as described in any one of claims 12 to 23.

27. A computer program product, characterized in that, When the computer program is executed by a processor, it implements the data protection method as described in any one of claims 1 to 11 or the data protection method as described in any one of claims 12 to 23.

Images