CN114629708A

CN114629708A - Client request encryption transmission method, data decryption method and system

Info

Publication number: CN114629708A
Application number: CN202210270034.7A
Authority: CN
Inventors: 刘旭进; 陆旭明; 刘冲; 赵光军; 赵栋; 贺磊; 田东超
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-03-18
Filing date: 2022-03-18
Publication date: 2022-06-14

Abstract

The embodiment of the specification discloses an encryption transmission method, a data decryption method and a system of a client request. After a first service request of a client is obtained, whether the first service request needs to be encrypted or not can be determined according to a preset encryption rule, when the first service request needs to be encrypted, contents to be encrypted in the first service request are replaced by corresponding encrypted contents, and an obtained second service request is sent to a server. When receiving the server data, determining whether the server data needs to be decrypted according to a preset decryption rule, and when the server data needs to be decrypted, replacing the encrypted content in the server data with the corresponding decrypted content to obtain the plaintext data required by the client.

Description

Client request encryption transmission method, data decryption method and system

Technical Field

The present disclosure relates to the field of information technology, and in particular, to an encryption transmission method, a data decryption method, and a system thereof for a client request.

Background

In the platform mode, the platform side is used as a business matching side and has necessary value, but the transparency of business data to the platform side increases the compliance risk on business. Nowadays, data privacy protection requirements are increasingly strict, and how to reduce the use cost of a client while effectively protecting data privacy based on a platform mode becomes a problem to be solved urgently.

Disclosure of Invention

One of embodiments of the present specification provides an encrypted transmission method for a client request, including: the method comprises the steps of obtaining a first service request of a client, wherein the first service request is used for requesting data service of a server; determining whether the first service request needs to be encrypted according to a preset encryption rule, replacing contents to be encrypted in the first service request with corresponding encrypted contents when the first service request needs to be encrypted so as to obtain a second service request, and sending the second service request to the service end.

One of the embodiments of the present specification provides an encrypted transmission system for a client request, which includes a first service request obtaining module and an encryption module. The first service request acquisition module is used for acquiring a first service request of a client; the first service request is used for requesting data service of a service end. The encryption module is configured to determine whether the first service request needs to be encrypted according to a preset encryption rule, and when the first service request needs to be encrypted, the encryption module is further configured to: replacing the content to be encrypted in the first service request with corresponding encrypted content to obtain a second service request; and sending the second service request to the server.

One of the embodiments of the present specification provides an apparatus for encrypted transmission of a client request, including a processor and a storage device, where the storage device is configured to store instructions. Wherein the processor, when executing the instructions, implements the method for encrypted transmission of a client request according to any embodiment of the present specification.

One of embodiments of the present specification provides a data decryption method, including: receiving server data; and determining whether the server data needs to be decrypted according to a preset decryption rule, and replacing the encrypted content in the server data with the corresponding decrypted content when the server data needs to be decrypted so as to obtain the plaintext data required by the client.

One of the embodiments of the present specification provides a data decryption system, which includes a server-side data receiving module and a decryption module. The server data receiving module is used for receiving server data. The decryption module is used for determining whether the server data needs to be decrypted according to a preset decryption rule, and when decryption is needed, the decryption module is further used for replacing the encrypted content in the server data with the corresponding decrypted content so as to obtain the plaintext data required by the client.

One of the embodiments of the present specification provides a data decryption apparatus, including a processor and a storage device, where the storage device is configured to store instructions. Wherein the processor, when executing the instructions, implements a data decryption method as described in any of the embodiments of the present specification.

Drawings

The present description will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structures, wherein:

FIG. 1 is a schematic diagram of an application scenario of a data privacy protection system in accordance with some embodiments of the present description;

FIG. 2 is an exemplary flow diagram of a method for encrypted transmission of a client request in accordance with some embodiments of the present description;

FIG. 3 is an exemplary flow diagram of a data decryption method according to some embodiments of the present description;

FIGS. 4A-4F are schematic diagrams of configuration pages according to some embodiments of the present description;

FIG. 5 is an exemplary block diagram of a client requested encrypted transmission system in accordance with some embodiments of the present description;

fig. 6 is an exemplary block diagram of data decryption, shown in accordance with some embodiments of the present description.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only examples or embodiments of the present description, and that for a person skilled in the art, the present description can also be applied to other similar scenarios on the basis of these drawings without inventive effort. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.

It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, portions or assemblies of different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.

As used in this specification, the terms "a", "an" and/or "the" are not intended to be inclusive of the singular, but rather are intended to be inclusive of the plural, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.

Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of the present specification. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.

Fig. 1 is a schematic diagram of an application scenario of a data privacy protection system according to some embodiments of the present description. As shown in FIG. 1, system 100 may include one or more clients 110, one or more servers 120, and a network 130.

Client 110 may refer to a user device for obtaining data services to server 120, which may communicate with server 120 by installing client software (e.g., a browser or other application, such as an APP). The user may include a data provider that uploads local data to the server 120 and a data consumer that obtains target data from the server 120. In some embodiments, the data provider and the data consumer may be different parties, for example, the data provider may be a seller providing information (e.g., an offer) for the goods, and the data consumer may be a buyer purchasing the goods. In still other embodiments, the data provider and the data consumer may be the same party, for example, the data provider may not only provide sample data required for model training to the server 120, but also may obtain the trained model from the server 120.

The server 120 may refer to a platform-side device that provides data services. The server 120 may obtain data to be processed from the client 110 of the data provider, process the data to be processed, and send the processed target data to the client 110 of the data consumer. In some implementations, two or more servers 120 may cooperate to process raw data from one or more data providers into target data. For example, the complete machine learning service is subdivided into three sub-services of data fusion, model training, and model distribution, and each sub-service may be provided by one server 120. The server 120 responsible for data fusion fuses the original data from multiple data providers, and sends the training sample set obtained by fusion to the server 120 responsible for model training. The server 120 responsible for model training performs model training by using the training sample set, and sends the complete model obtained by training to the server 120 responsible for model distribution. The server 120 responsible for model distribution splits the complete model and distributes the split submodels to a plurality of model users.

In order to avoid the leakage of the privacy of the user, data security needs to be ensured in the data transmission and data processing processes. Specifically, the client 110 may encrypt the local data and upload the encrypted data to the server 120. The server 120 may process the data using privacy protection techniques and send the resulting data in ciphertext form to the client 110. In some embodiments, the privacy preserving techniques that may be used include one or more of homomorphic encryption, TEE, container (e.g., docker), and the like. Accordingly, the client 110 can obtain the result data in a plain text form by decryption.

However, for client users, encryption and decryption may increase their system usage cost to some extent, and the user experience is not friendly. Specifically, users using clients are often not professionals in the field of cryptography, and learning and mastering encryption and decryption skills increases their burden to a certain extent; the user needs to encrypt the content to be encrypted and then inputs the encrypted content to generate an encrypted service request, so that the user experience is poor.

In view of this, the embodiments of the present disclosure provide an encryption and decryption scheme imperceptible to a user, which can reduce the system use cost of the user and improve the user experience. With regard to the details of the encrypted portion, reference may be made to fig. 2 and its associated description. With regard to the details of the decryption portion, reference may be made to fig. 3 and its associated description.

In some embodiments, the user end 110/service end 120 may include various types of computing devices, such as smart phones, tablet computers, laptop computers, desktop computers, workstations, servers, and the like. Wherein a server may be a stand-alone server or a group of servers, which may be centralized or distributed. In some embodiments, the server may be regional or remote. In some embodiments, the server may execute on a cloud platform. For example, the cloud platform may include one or any combination of a private cloud, a public cloud, a hybrid cloud, a community cloud, a decentralized cloud, an internal cloud, and the like.

The network 130 connects the various components of the system so that communication can occur between the various components. The network between the various parts in the system may include wired networks and/or wireless networks. For example, network 130 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network (ZigBee), Near Field Communication (NFC), an intra-device bus, an intra-device line, a cable connection, and the like, or any combination thereof. The network connection between each two parts may be in one of the above-mentioned ways, or in a plurality of ways.

Fig. 2 is an exemplary flow diagram of a method for encrypted transmission of a client request, according to some embodiments of the present description. The process 200 may be performed by a client acting as a requestor. As shown in fig. 2, the process 200 may include the following steps.

Step 210, a first service request of the client is obtained, where the first service request is used to request a data service of the server. In some embodiments, step 210 may be performed by first service request acquisition module 510.

In some embodiments, if the complete data service is subdivided into a plurality of sub-services to be provided by a plurality of service terminals, the requested party (or called responding party) of the first service request may be the service terminal providing the first sub-service, for example, the service terminal providing the data fusion service in the foregoing example. In some embodiments of this specification, a service request does not necessarily mean that a client sending the request needs to obtain, from a server, a result of processing relevant data by the server in response to the request, and in particular, the service request may be broadly understood to include a case where the client will make a data service request to the server, and request the server to perform relevant data processing, but does not require the server to feed back a processing result to the client.

Step 220, determining whether the first service request needs to be encrypted according to a preset encryption rule.

The encryption rules may indicate under what circumstances (e.g., when conditions are met) the service request needs to be encrypted. When it is determined that the first service request requires encryption, the client may proceed to step 230. In some embodiments, the client may send the first service request to the server when it is determined that the first service request does not require encryption. In some embodiments, when it is determined that the first service request does not require encryption, the client may add an unencrypted text identifier to the first service request to obtain a second service request, and send the second service request to the server.

In some embodiments, the encryption rule may indicate that a service request is determined to require encryption when the service request contains a specified field to be encrypted or a file to be encrypted. Specifically, the client may detect whether the first service request includes a field to be encrypted or a file to be encrypted, which is specified by an encryption rule, and when the client detects that the first service request includes the field to be encrypted or the file to be encrypted, that is, the first service request needs to be encrypted, the client may continue to perform step 230 with a value of the field to be encrypted in the first service request or with the file to be encrypted in the first service request as at least part of the content to be encrypted. For example only, for a certain encryption rule, the specified field to be encrypted may be a prime field (identification PRICE), and when the client detects that the first service request contains the prime field, it may be determined that the first service request needs to be encrypted, and then step 230 may be continued with the value of the prime field in the first service request as at least part of the content to be encrypted. For another encryption rule, the specified file to be encrypted may include a voice file, and when the client detects that the first service request includes a voice file, it may be determined that the first service request needs to be encrypted, and then the step 230 may be performed by taking the voice file in the first service request as at least part of the content to be encrypted.

It should be noted that a field in this specification may refer to a certain attribute of an entity (e.g., a service request), and a set of attributes of the entity may constitute a complete record of the entity, that is, the field is a constituent unit of the record. A file in this specification may refer to a collection of information stored on a computer carried on a hard disk of the computer, and typically a file suffix may indicate the file type/format, e.g. wav is one of the sound file formats.

In some embodiments, the encryption rule may indicate that a service request needs to be encrypted when a server identity in the service request belongs to a specified target server identity. That is, when requesting a data service from a server specified by an encryption rule, the client needs to encrypt the service request. Specifically, the first service request may include an identifier of a requested service end, the client may determine whether the identifier of the service end belongs to the target service end identifier specified by the encryption rule, and when the identifier of the service end belongs to the target service end identifier specified by the encryption rule, that is, the first service request needs to be encrypted, the client may continue to perform step 230. Taking an HTTP (hypertext Transfer Protocol) request as an example, the encryption rule may indicate that a service request needs to be encrypted when a URL (Uniform Resource Locator) prefix in the service request satisfies a specified format "HTTP:// xxx. That is, when a data service is requested to a server having an access address of "http:// xxx. com/donpa/api/", the client needs to encrypt the service request.

Step 230, replacing the content to be encrypted in the first service request with the corresponding encrypted content to obtain a second service request.

In some embodiments, the content to be encrypted may be determined based on the encryption rule. It should be understood that a plurality of encryption rules may be set, and the content to be encrypted is determined by traversing the plurality of encryption rules. The content to be encrypted may include a field to be encrypted and/or a file to be encrypted. For more details regarding the determination of the content to be encrypted based on the encryption rules, reference may be made to the related description above.

In some embodiments, the content to be encrypted may also be determined in other ways. For example, the service request may include a request header and a request body, and when it is determined that the first service request needs to be encrypted, the client may determine the request body of the first service request as the content to be encrypted. For another example, the field to be encrypted or the file to be encrypted may also be unrelated to the encryption rule, and when it is determined that the first service request needs to be encrypted, the client may determine the field and/or the file in the first service request as the content to be encrypted.

In some embodiments, the client may encrypt the content to be encrypted by using its corresponding symmetric key to obtain the corresponding encrypted content. It should be understood that the client may inform the server in advance of its symmetric key for encrypting the content to be encrypted.

After the content to be encrypted in the first service request is encrypted, a second service request can be obtained. In some embodiments, the encrypted content in the second service request may have a corresponding ciphertext identification to indicate that the encrypted content is ciphertext. Therefore, the server side can decrypt the encrypted content corresponding to the ciphertext identifier to obtain the plaintext content (namely the content to be encrypted). It should be understood that a ciphertext flag may be set for each encrypted field/encrypted file in the encrypted content, for example, a prefix may be added to the value of the encrypted field to indicate that the field is encrypted (e.g., "en: ABC", where "en:" is the added prefix, meaning that ABC is ciphertext), and for example, a prefix may be added to the filename of the encrypted file to indicate that the file is encrypted (e.g., "en: xxx. wav" indicates that the file with the filename xxx. wav is encrypted). The encrypted field/encrypted file is an encrypted result of the field/file to be encrypted, that is, the encryption can be performed in units of fields/files. In some embodiments, the same ciphertext identifier may also be added to the field to be encrypted/the file to be encrypted in the first service request, so as to locate the field to be encrypted/the file to be encrypted in the first service request, and the ciphertext identifier may be retained after encryption replacement, so as to indicate that the encrypted content is a ciphertext. For example, assuming that the first service request contains a field to be encrypted, which has a value of 150, specifically may include "en: 150", the client may determine "150" as the content to be encrypted according to "en: 150", and assuming that ABC is obtained by encrypting 150, the field becomes "en: ABC" after encryption "en: 150".

Step 240, sending the second service request to the server.

In some embodiments, steps 220 through 240 may be performed by encryption module 520.

The server may decrypt the encrypted content in the second service request to obtain the corresponding decrypted content (i.e., the content to be encrypted) and process the decrypted content.

In some embodiments, the client may transmit a symmetric key for encrypting the content to be encrypted to the server in a secure manner. Specifically, the client may encrypt the symmetric key with a public key corresponding to the server to obtain an encryption result of the symmetric key, and send the encryption result of the symmetric key to the server along with the second service request, for example, the encryption result of the symmetric key may be placed in a request header. Of course, the encryption result of the symmetric key may also be sent to the server separately, i.e. without following the second service request. After receiving the encryption result of the symmetric key, the server side can decrypt the encryption result of the symmetric key by using the private key corresponding to the server side to obtain the symmetric key, and further can decrypt the encrypted content corresponding to the content to be encrypted by using the symmetric key to obtain decrypted content (namely the content to be encrypted).

In some embodiments, the server side following the second service request may further include digital signature information, where the digital signature information is a result of digitally signing (i.e., encrypting) the symmetric key by using a corresponding private key of the client side. In this way, the server may verify the digital signature information by using the public key corresponding to the client, specifically, the server may decrypt the digital signature information by using the public key corresponding to the client, and decrypt the encryption result of the symmetric key by using the public key corresponding to the server, and when two plaintext obtained by decryption are the same, it is indicated that the symmetric key obtained by decryption is from the client. That is, the digital signature information may prove the source of the symmetric key.

In some embodiments, the client may encrypt the content to be encrypted by using the public key corresponding to the server to obtain the corresponding encrypted content. Correspondingly, the server side can decrypt the encrypted content by using the private key corresponding to the server side to obtain decrypted content (namely the content to be encrypted).

In some embodiments, the first service request may be for requesting a data service of a server target trusted zone application. A Trusted area application (also referred to as TAPP or TA) may refer to an application program running in a Trusted Execution Environment (TEE). TEE is a secure environment isolated from the Operating System (OS) and can provide confidentiality and non-tamper for code execution and data storage. Specifically, each trusted zone application may correspond to a pair of public and private keys, which may be referred to as a public key and a private key of the TAPP, and the TAPP may decrypt input data using a local private key, where the input data is obtained by encrypting plaintext data using the public key of the TAPP. The TAPP may encrypt data before outputting the data, and output the encrypted data. It is to be understood that the data to and from the TEE may be encrypted to ensure data security. When the first service request is used for requesting a data service of a target trusted area application of a server, the public key corresponding to the server refers to a public key corresponding to the target trusted area application. For example, the encryption result of the symmetric key may refer to a result of encrypting the symmetric key with a corresponding public key of the target trusted zone application, and accordingly, the target trusted zone application may perform the following procedure in the TEE: decrypting the encryption result of the symmetric key by using a local private key to obtain the symmetric key; decrypting the encrypted content in the second service request by using the symmetric key to obtain data to be processed; processing the data to be processed to obtain result data; and encrypting the result data and routing the encryption result of the result data. For another example, the client may encrypt the content to be encrypted by using the public key corresponding to the target trusted zone application, so as to obtain the corresponding encrypted content. Accordingly, the target trusted zone application may perform the following in the TEE: decrypting the encrypted content in the second service request by using a local private key to obtain data to be processed; processing the data to be processed to obtain result data; and encrypting the result data and routing the encryption result of the result data.

In some embodiments, the second service request may further include an identification of the target trusted zone application to instruct the server to forward the second service request to the target trusted zone application for processing. In some embodiments, the second service request may further include an identifier of the requested data service, so that the service end determines the target trusted area application capable of providing the data service according to the identifier of the data service, and forwards the second service request to the target trusted area application for processing. In some embodiments, the server may directly determine that the target trusted zone application can be provided according to the data content of the second service request, and forward the second service request to the target trusted zone application for processing. For example, when the second request service includes a plurality of training samples, the server may directly send the second service request to the target trusted zone application for data fusion.

The process 200 can implement encrypted transmission of the service request by intercepting the service request, encryption judgment and encryption replacement, the whole process is imperceptible to the user, and the user does not need to change the habit of initiating the service request for encryption (the user can initiate the first service request without encryption processing as usual), so that better user experience can be brought.

FIG. 3 is an exemplary flow diagram of a method of decrypting data, according to some embodiments of the present description. The process 300 may be performed by a client of a data consumer. As shown in fig. 3, the process 300 may include the following steps.

At step 310, server data is received. In some embodiments, step 310 may be performed by server data receiving module 610.

The server data may contain target data that the server sends to the client of the data consumer in response to a service request by the data provider. Referring to the foregoing embodiments, the data provider and the data consumer may be the same party or different parties.

In some embodiments, the server data may also contain an identification of the server, which may include a network address in the form of a URL, for example, in response to an HTTP request.

Step 320, determining whether the server data needs to be decrypted according to a preset decryption rule.

The decryption rule may indicate under what circumstances (e.g., when conditions are met) the server data needs to be encrypted. When it is determined that the server data needs to be encrypted, the client can proceed to step 330.

In some embodiments, the decryption rule may indicate that server data needs to be decrypted when the server data contains a specified encrypted field or encrypted file. Specifically, the client may detect whether the received server data includes an encrypted field or an encrypted file specified by the decryption rule, and when the client detects that the server data includes the encrypted field or the encrypted file, that is, the server data needs to be decrypted, the client may continue to perform step 330 with the value of the encrypted field in the server data or with the encrypted file in the server data as at least part of the encrypted content. For example only, for a certain decryption rule, the specified encryption field may be a prime field (identification PRICE), and when the client detects that the received server data contains the prime field, it may be determined that the server data needs to be decrypted, and then step 230 may be continued with the value of the prime field in the server data as at least part of the encrypted content. For another decryption rule, the specified encrypted file may include a voice file, and when the client detects that the received server data contains the voice file, it may be determined that the server data needs to be decrypted, and then step 330 may be performed to continue with the voice file in the server data as at least part of the encrypted content.

In some embodiments, the decryption rule may indicate that the server data needs to be decrypted when a server identifier in the server data belongs to a specified target server identifier. That is, when receiving data from the server specified by the decryption rule, the client needs to decrypt the received server data. Specifically, the server data may include an identifier of the server, and the client may determine whether the identifier of the server belongs to the target server identifier specified by the decryption rule, and when the identifier of the server belongs to the target server identifier specified by the decryption rule, that is, when the server data needs to be decrypted, the client may continue to perform step 330. For example, the decryption rule may indicate that the server data needs to be encrypted when a URL (Uniform Resource Locator) prefix in the server data satisfies a specified format "http:// xxx. com/donpa/api/". That is, when the server data is obtained from the server with the address "http:// xxx. com/donpa/api/", the client needs to decrypt the server data.

Step 330, replacing the encrypted content in the server data with the corresponding decrypted content to obtain the plaintext data required by the client.

In some embodiments, steps 320 and 330 may be performed by decryption module 620.

In some embodiments, the encrypted content in the server data may be located by ciphertext identification. Specifically, the encrypted content in the server data may have a corresponding ciphertext identifier to indicate the encrypted content. Therefore, the client can determine the encrypted content in the server data based on the ciphertext identifier and decrypt the encrypted content to obtain the corresponding decrypted content. For more details on the ciphertext identifier, reference may be made to the description above for the ciphertext identifier in the second service request. In addition, the ciphertext identifier in the second service request and the ciphertext identifier in the server data may be distinguished, for example, "en" may be used as the ciphertext identifier in the second service request to indicate that the corresponding content needs to be encrypted, and "de" may be used as the ciphertext identifier in the server data to indicate that the corresponding content needs to be decrypted.

In some embodiments, the encrypted content in the server data may be determined based on a decryption rule. It should be appreciated that multiple decryption rules may be set, with encrypted content being determined by traversing the multiple decryption rules. The encrypted content may include an encrypted field and/or an encrypted file. For more details on determining the decrypted content based on the decryption rules, reference may be made to the related description above.

In some embodiments, the encrypted content in the server data may also be determined in other ways. For example, the server data may include two parts, a header and a body, and when it is determined that the server data needs to be decrypted, the client may determine the body part of the server data as the encrypted content. For another example, the encrypted field/encrypted file may also be independent of the decryption rule, and when it is determined that the server data needs to be decrypted, the client may determine the encrypted field and/or the encrypted file in the server data as the encrypted content.

In some embodiments, the client may decrypt the encrypted content in the server data by using its corresponding symmetric key, to obtain the corresponding decrypted content. Correspondingly, the encrypted content is a result of the server encrypting the decrypted content (such as target data obtained by the server through data processing) by using the symmetric key corresponding to the client. For details of the server obtaining the symmetric key corresponding to the client, reference may be made to the foregoing embodiments.

In some embodiments, the client may decrypt the encrypted content in the server data to the corresponding decrypted content using a local private key. Correspondingly, the encrypted content is a result of the server encrypting the decrypted content (such as target data obtained by the server through data processing) by using the public key corresponding to the client.

The process 300 can realize decryption of server data by intercepting server data, decryption judgment and decryption replacement, the whole process is not sensitive to a user, and the user can directly obtain the server data subjected to decryption processing, so that better user experience can be brought.

In some embodiments, the process 200 and/or the process 300 (which may be collectively referred to as an encryption/decryption process) may be implemented by a plug-in installed at the client, where the plug-in is a functional extension of existing software of the client, and has the advantages of light weight, convenience in installation, easiness in use, and the like. For example only, the process 200/300 may be implemented by a browser plug-in, and a user may install a plug-in for implementing an encryption/decryption process in a commonly used browser, so that a client browser may automatically implement encryption/decryption without the user's perception, and the user does not need to change his/her habit of using the browser.

In some embodiments, a configuration page for encrypting and decrypting flow-related items may be provided for a user to view and configure the related items. For example, the preset encryption rule/decryption rule may be configured by a user through a configuration page. Further, the preset encryption rule/decryption rule can be exported through a configuration page to obtain a corresponding rule configuration file. Correspondingly, the preset encryption rule/decryption rule can be obtained by importing a rule configuration file through a configuration page by a user. The import and export of the rule profile facilitates the replication of encryption and decryption rules between multiple clients of the same business or between multiple businesses of the same (or similar) business. As another example, the key used for encryption/decryption may also be configured by the user through a configuration page. For more details on the configuration page, reference may be made to fig. 4A-4F and their associated description.

Fig. 4A-4F are schematic diagrams of configuration pages according to some embodiments of the present description.

As shown in fig. 4A to 4F, the configuration page may include 6 sub-pages of TAPP setting, symmetric key setting, asymmetric key setting, encryption rule, decryption rule, and configuration management. After the user selects (e.g., mouse click, touch, etc.) one of the 6 strip areas on the left side, the corresponding sub-page can be displayed on the right side. The 6 sub-pages are described one by one below.

The TAPP setup page shown in fig. 4A may be used to configure and present various items of information (TAPP information) of one or more TAPPs (e.g., TAPP1 and TAPP2 in the figure), and the information items of each TAPP may include an identification (tappid), a version (version) and a corresponding public key (pk) of the TAPP. The user can add various items of information of the TAPP by selecting the strip area marked with the word pattern of 'adding TAPP' at the upper right corner of the page, and the user can delete various items of information of the TAPP by selecting the strip area marked with the word pattern of 'deleting' near various items of information of a certain TAPP.

The symmetric key setup page shown in fig. 4B may be used to configure and display the symmetric key corresponding to the client. Each client may correspond to one or more symmetric keys that may be used for secure communication of the client with the one or more TAPPs, respectively, i.e., the client may set a private symmetric key for each TAPP (as shown, one key under each tappid). When requesting a data service from a target TAPP, the client can encrypt contents to be encrypted using a private symmetric key set for the target TAPP. When the received server data comes from the target TAPP, the client can decrypt the encrypted content using the private symmetric key set for the target TAPP.

The asymmetric key page shown in fig. 4C may be used to configure and present a public-private key pair corresponding to a client. Each client may correspond to one or more sets of public and private key pairs, which may be respectively used for secure communication between the client and the one or more TAPPs, that is, the client may set a dedicated public and private key pair for each TAPP (as shown, there is a pair pk and sk under each tappid). When requesting data services from a target TAPP, a client may digitally sign a private key in a private public-private key pair set for the target TAPP. Accordingly, the target TAPP can verify the digital signature information using the public key in the private and public key pair set for it by the client. It is to be appreciated that the client can inform the target TAPP of the public key in the private and public key pair set for it.

The encryption setup page shown in fig. 4D may be used to configure and present one or more preset encryption rules. For example, encryption rule 1 in the figure indicates that for a service request containing the URL prefix "http:// xxx. com/donpa/api/", the field with the encryption identification (i.e. the aforementioned ciphertext identification) "en" in the request is replaced by encryption. In addition, the encryption rule 1 also specifies a file to be encrypted (i.e. the file to be encrypted), and the user can configure the file to be encrypted by selecting a circular area marked with an "encryption" character on the right side of the long strip area marked with the "file" character. For example only, after the user selects the circular area, the configuration page may pop up a dialog box, the dialog box may display a plurality of candidate file formats for the user to select, and further, the client may determine the file in the format selected by the user as the file to be encrypted specified by the encryption rule 1. The user can add the encryption rule by selecting the strip-shaped area marked with the word of 'adding rule' at the upper right corner of the page, and the user can delete the encryption rule by selecting the strip-shaped area marked with the word of 'deleting' near each item of information of a certain encryption rule.

The decryption settings page shown in fig. 4E may be used to configure and present one or more preset decryption rules. For example, decryption rule 1 in the figure indicates that for a service request containing the URL prefix "http:// xxx. com/donpa/api/", the field with the decryption identifier (i.e. the aforementioned ciphertext identifier) "de" in the request is decrypted instead. In addition, the decryption rule 1 also specifies the file to be decrypted (i.e. the encrypted file), and the user can configure the file to be decrypted by selecting the circular area marked with the word "decrypt" on the right side of the long strip area marked with the word "file". For example only, after the user selects the circular area, the configuration page may pop up a window, which may display a plurality of candidate file formats for the user to select, and further, the client may determine a file in a format selected by the user (e.g., a file in wav format) as the encrypted file specified by the decryption rule 1. The user can add the decryption rule by selecting the long strip area marked with the word of 'adding rule' at the upper right corner of the page, and the user can delete the decryption rule by selecting the long strip area marked with the word of 'deleting' near each item of information of a certain decryption rule.

The configuration management page shown in fig. 4F may be used to import/export a rule configuration file. When a file is imported, a user can store a rule configuration file to be imported into a client in a certain file path in advance, then the user can select a long strip area marked with a character of 'import from file', and the rule configuration file under the file path is selected in a popped file resource manager interface, so that the rule configuration file is imported into the client. When the file is exported, a user can select a long strip area marked with the character of exporting to the file, a file storage path is selected for the rule configuration file to be exported on a popped file resource manager interface, and then the background can automatically generate the rule configuration file based on the encryption rule and the decryption rule configured by the user and store the rule configuration file to the file storage path selected by the user.

It should be noted that the above description of the flow is for illustration and description only and does not limit the scope of the application of the present specification. Various modifications and changes to the flow may occur to those skilled in the art, given the benefit of this disclosure. However, such modifications and variations are intended to be within the scope of the present description.

Fig. 5 is an exemplary block diagram of a client requested encrypted transmission system in accordance with some embodiments of the present description. System 500 may be implemented on a client.

As shown in fig. 5, the system 500 may include a first service request acquisition module 510 and an encryption module 520.

The first service request obtaining module 510 may be configured to obtain a first service request of a client, where the first service request is for requesting a data service of a server.

The encryption module 520 may be configured to determine whether the first service request needs to be encrypted according to a preset encryption rule. When encryption is required, the encryption module 520 may also be configured to: replacing the content to be encrypted in the first service request with corresponding encrypted content to obtain a second service request; and sending the second service request to the server.

For more details on the system 500 and its modules, reference may be made to fig. 2 and its associated description.

Fig. 6 is an exemplary block diagram of data decryption, shown in accordance with some embodiments of the present description. System 600 may be implemented on a client.

As shown in fig. 6, system 600 may include a server-side data receiving module 610 and a decryption module 620.

The server data receiving module 610 may be configured to receive server data.

The decryption module 620 may be configured to determine whether the server data needs to be decrypted according to a preset decryption rule. When decryption is needed, the decryption module 620 may be further configured to replace the encrypted content in the server data with the corresponding decrypted content to obtain the plaintext data required by the client.

For more details regarding system 600 and its modules, reference may be made to FIG. 3 and its associated description.

It should be understood that the systems shown in fig. 5 and 6 and their modules may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).

It should be noted that the above description of the system and its modules is for convenience only and should not limit the present disclosure to the illustrated embodiments. It will be appreciated by those skilled in the art that, given the teachings of the system, any combination of modules or sub-system configurations may be used to connect to other modules without departing from such teachings. For example, in some embodiments, the encryption module 520 may be a single module, or may be implemented by two sub-modules, where one sub-module may be configured to determine whether the first service request needs to be encrypted according to a preset encryption rule, and when the first service request needs to be encrypted, the other sub-module may be configured to: replacing the content to be encrypted in the first service request with corresponding encrypted content to obtain a second service request; and sending the second service request to the server. Such variations are within the scope of the present disclosure.

The beneficial effects that may be brought by the embodiments of the present specification include, but are not limited to: (1) the method has the advantages that the access and use cost of the client is reduced while effective privacy protection is carried out on data based on a platform mode; (2) the related functions can be realized by the plug-in installed at the client, and the plug-in is a function expansion of the existing software of the client, and has the advantages of light weight, convenience in installation, easiness in use and the like. It is to be noted that different embodiments may produce different advantages, and in different embodiments, the advantages that may be produced may be any one or combination of the above, or any other advantages that may be obtained.

Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be considered merely illustrative and not restrictive of the embodiments herein. Various modifications, improvements and adaptations to the embodiments described herein may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the embodiments of the present specification and thus fall within the spirit and scope of the exemplary embodiments of the present specification.

Also, the description uses specific words to describe embodiments of the description. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the specification. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the specification may be combined as appropriate.

Moreover, those skilled in the art will appreciate that aspects of the embodiments of the present description may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereof. Accordingly, aspects of embodiments of the present description may be carried out entirely by hardware, entirely by software (including firmware, resident software, micro-code, etc.), or by a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the embodiments of the present specification may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.

The computer storage medium may comprise a propagated data signal with the computer program code embodied therewith, for example, on baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.

Computer program code required for operation of various portions of the embodiments of the present description may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages, and the like. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or processing device. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).

In addition, unless explicitly stated in the claims, the order of processing elements and sequences, use of numbers and letters, or use of other names in the embodiments of the present specification are not intended to limit the order of the processes and methods in the embodiments of the present specification. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing processing device or mobile device.

Similarly, it should be noted that in the preceding description of embodiments of the specification, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more embodiments of the invention. This method of disclosure, however, is not intended to imply that more features are required than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.

For each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., cited in this specification, the entire contents of each are hereby incorporated by reference into this specification. Except where the application is filed in a manner inconsistent or contrary to the present specification, and except where a claim is filed in a manner limited to the broadest scope of the application (whether present or later appended to the application). It is to be understood that the descriptions, definitions and/or uses of terms in the accompanying materials of this specification shall control if they are inconsistent or contrary to the descriptions and/or uses of terms in this specification.

Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present disclosure. Other variations are possible within the scope of the embodiments of the present description. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the specification can be considered consistent with the teachings of the specification. Accordingly, the embodiments of the present description are not limited to only those embodiments explicitly described and depicted herein.

Claims

1. A method of encrypted transmission of a client request, comprising:

acquiring a first service request of a client; the first service request is used for requesting data service of a service end;

determining whether the first service request needs to be encrypted according to a preset encryption rule, and when the first service request needs to be encrypted:

replacing the content to be encrypted in the first service request with corresponding encrypted content to obtain a second service request; and sending the second service request to the server.

2. The method of claim 1, further comprising:

and when the encryption is not needed, the first service request is sent to the server.

3. The method of claim 1, wherein the first service request contains an identification of the server; the determining whether the first service request needs to be encrypted according to a preset encryption rule includes:

and when the identification of the server belongs to the target server identification specified by the encryption rule, determining that the first service request needs to be encrypted.

4. The method of claim 1, wherein the replacing the content to be encrypted in the first service request with the corresponding encrypted content to obtain a second service request comprises:

encrypting the content to be encrypted by using a symmetric key corresponding to the client to obtain the corresponding encrypted content;

and the encrypted content in the second service request has a corresponding ciphertext identifier so as to indicate that the encrypted content is a ciphertext.

5. The method of claim 4, wherein the encryption result sent following the second service request further includes the symmetric key; the encryption result of the symmetric key comprises a result of encrypting the symmetric key by using a public key corresponding to the server.

6. The method of claim 5, further comprising, following the second service request, digitally signing information; the digital signature information comprises a result of digitally signing the symmetric key by using a private key corresponding to the client.

7. The method of claim 5, wherein the first service request is for requesting a data service of a server target trusted zone application; and the public key corresponding to the server is the public key corresponding to the target trusted area application.

8. The method of claim 7, wherein the second service request further includes an identification of the target trusted zone application to instruct a server to forward the second service request to the target trusted zone application for processing.

9. The method of claim 1, wherein the content to be encrypted is determined based on the encryption rule, which includes a field to be encrypted and/or a file to be encrypted.

10. The method of claim 1, wherein the method is implemented by a plug-in for installation at the client.

11. The method of claim 1, wherein the preset encryption rule is configured by a user through a configuration page or by importing a rule configuration file.

12. The method of claim 1, wherein the preset encryption rules can be exported through a configuration page to get a corresponding rule profile.

13. An encrypted transmission system of a client request comprises a first service request acquisition module and an encryption module;

the first service request acquisition module is used for acquiring a first service request of a client; the first service request is used for requesting data service of a service end;

the encryption module is used for determining whether the first service request needs to be encrypted according to a preset encryption rule, and when the first service request needs to be encrypted:

the encryption module is further configured to: replacing the content to be encrypted in the first service request with corresponding encrypted content to obtain a second service request; and sending the second service request to the server.

14. An encrypted transmission device of a client request, comprising a processor and a storage device, wherein the storage device is used for storing instructions, and when the processor executes the instructions, the encrypted transmission method of the client request according to any one of claims 1 to 12 is realized.

15. A method of data decryption, comprising:

receiving server data;

determining whether the server data needs to be decrypted according to a preset decryption rule, and when the server data needs to be decrypted:

and replacing the encrypted content in the server data with the corresponding decrypted content to obtain the plaintext data required by the client.

16. The method of claim 15, wherein the server data contains an identification of the server; the determining whether the server data needs to be decrypted according to a preset decryption rule includes:

and when the identification of the server belongs to the target server identification specified by the decryption rule, determining that the server data needs to be decrypted.

17. The method of claim 15, wherein the encrypted content in the server data has a corresponding ciphertext identification to indicate that the encrypted content is ciphertext;

replacing the encrypted content in the server data with the corresponding decrypted content to obtain plaintext data, including:

determining encrypted content in the server data based on the ciphertext identification;

and decrypting the encrypted content by using the symmetric key corresponding to the client to obtain the corresponding decrypted content.

18. The method of claim 15, wherein the method is implemented by a plug-in for installation at the client.

19. The method of claim 15, wherein the preset decryption rule is configured by a user through a configuration page or by importing a rule configuration file.

20. The method of claim 15, wherein the preset decryption rules can be exported through a configuration page to get a corresponding rule profile.

21. A data decryption system comprises a server data receiving module and a decryption module;

the server data receiving module is used for receiving server data;

the decryption module is used for determining whether the server data needs to be decrypted according to a preset decryption rule, and when decryption is needed:

the decryption module is further used for replacing the encrypted content in the server data with the corresponding decrypted content to obtain the plaintext data required by the client.

22. A data decryption apparatus comprising a processor and a storage device, the storage device being arranged to store instructions, wherein the processor, when executing instructions, implements a data decryption method as claimed in any one of claims 15 to 20.