Data security sharing method and system in untrusted environment

Abstract

The present invention proposes a data security sharing system and method in a non-trusted environment, the system includes a central platform system and a front-end system; the central platform system is placed in a third-party trusted cloud, and the front-end system is placed in the internal security area of ​​each data owner; the central platform system is responsible for communicating with each front-end system and data transfer processing, and the front-end system serves as a connection intermediary system between the central platform system and the client system. The present invention provides a variety of privacy protection mechanisms, including homomorphic encryption, secret sharing, differential privacy, trusted execution environment, etc. The centralized architecture can avoid the risk of single-point privacy leakage, meet the data analysis and mining process of multiple subjects based on business needs, solve the problem of multi-party data in a non-trusted environment. Safe and reliable fusion and data application, ensure that the data provided by each party is not leaked, and maximize the guarantee that the data after security protection can meet the business application requirements of all parties.

Description

Technical field:

[0001] The present invention relates to the field of data security sharing, and in particular to a data security sharing method and system in a non-trusted environment. Background technology:

[0002] Currently, multiple data subjects mainly include three categories: State Grid Corporation, government agencies, and enterprises. The data of State Grid Corporation is currently all in the intranet built by itself, while the data of government agencies, including sensitive privacy-related data, are all in the government affairs or the agency’s own intranet; enterprise data is mainly within the enterprise, and sensitive privacy-related data is strictly stored within the enterprise.

[0003] Even if multiple data subjects do not exchange specific data records, but only exchange the statistical characteristics of each party's data, there is still a risk of leaking the privacy of each party's data. Based on business needs, in the process of data analysis and mining, it is necessary to use external data to complete the governance and improvement of own data and expand information. Therefore, multiple data subjects have an urgent need for data sharing.

[0004] However, the existing technology lacks a multi-party trusted environment to meet the needs of information sharing among multiple data subjects. The encryption-based data security transmission method used in the power system is difficult to prevent such privacy leakage, and it is even more difficult to take into account the availability of data features. At the same time, there is also a lack of pilot verification for multi-data subject fusion technology. Summary of the invention:

[0005] The purpose of this invention is to solve the needs of State Grid Corporation and multiple parties such as government agencies, banks, and enterprises for data exchange, and to solve the architectural design of data security sharing in a non-trusted environment.

[0006] Specifically, the present invention proposes a data security sharing system in a non-trusted environment, the system comprising a central platform system and a front-end system; the central platform system is placed in a third-party trusted cloud, and the front-end system is placed in the internal security area of ​​each data owner; the central platform system is responsible for communicating with each front-end system and data transfer processing, and the front-end system serves as a connection intermediary system between the central platform system and the client system.

[0007] Preferably, the central platform system and the front-end system use two-way login authentication to ensure information security; that is, when the front-end system initiates a request and calls the central platform system, it needs to carry the central platform system token authentication information, and when the central platform system calls the front-end system, it also needs to carry the client authentication token.

[0008] Preferably, dedicated lines are established between the central platform system and the front-end system, and between the front-end system and the internal application system, and network communication is performed through the https protocol.

[0009] Preferably, the Https is composed of HTTP+SSL / TLS, that is, a module for processing encrypted information is added to HTTP.

[0010] Preferably, the central platform system and the front-end system use signatures for access to prevent parameters from being tampered with or intercepted.

[0011] Preferably, the value of the signature includes non-empty parameters in ascending order, token authentication, verification code, current timestamp, and random password spliced ​​together; the random password includes a combination of numbers and letters, a 6-digit random number, encrypted using MD5, and passed in front of a parameter in the interface.

[0012] Preferably, before the server calls the interface, it will recalculate the previous value according to the signature rules and then compare it with the value of the signature parameter passed by the interface. If they are equal, it means that the parameter value has not been tampered with. If they are not equal, it means that the parameter has been illegally tampered with and the interface will not be executed.

[0013] Preferably, the timestamp is the current timestamp corresponding to when the client calls the interface. Each time the interface is called, the interface will determine the difference between the current system time of the server and the timestamp passed in the interface. If the difference exceeds the preset time, the request will be intercepted.

[0014] The present invention also proposes a data security sharing method in a non-trusted environment, the method comprising the following steps:

[0015] S1: Deploy the front-end system in the internal security area of ​​each data owner;

[0016] S2: Deploy the central platform system in a third-party trusted cloud;

[0017] S3: The data demander initiates a request to the front-end system and carries the data that needs to be calculated;

[0018] S4: After receiving the request, the front-end system encrypts the data using AES encryption technology and uses the RSA public key to encrypt the AES key. After completion, the AES encrypted value is placed in the custom request header.

[0019] S5: The front-end sends a request to the central platform, carrying the encrypted data;

[0020] S6: The central platform obtains the custom request header value, uses the RSA private key to decrypt and obtain the AES key, decrypts the parameter data using the AES key, and puts the data into a temporary database;

[0021] S7: The central platform system sends a data query instruction to the data owner's front-end machine according to the established business logic and parameter conditions, and uses the AES key of the data owner's front-end machine system to encrypt the parameters;

[0022] S8: After receiving the request from the central platform, the front-end system of the data owner decrypts the parameters using the AES key, and after decryption, sends a data request to the internal application system based on the parameter conditions;

[0023] S9: After the data owner's front-end system obtains the internal application system data, it uses the AES key to encrypt the data, and then uses the RSA public key to encrypt the AES key and put it into the custom request header. After completion, the data owner's front-end system sends the data to the central platform;

[0024] S10: After receiving the data, the central platform system uses the RSA private key to decrypt the request header to obtain the AES key, and then uses the AES key to decrypt the data. Through the actual business logic, it calculates with the data provided by the data demander to obtain the required results, and uses the AES key of the data demander's front-end to encrypt the results and return them to the data demander's front-end.

[0025] S11: After receiving the data from the center, the front-end of the data demander uses the AES key to decrypt the data and returns the result to the customer system;

[0026] S12: After the data delivery is completed, the central platform system clears all acquired data and does not save any data.

[0027] Compared with the prior art, the present invention has the following beneficial technical effects:

[0028] The present invention constructs a method and system for realizing secure data mining and sharing among multiple parties, solves the problem that data among industries and enterprises cannot be effectively integrated, solves the problem of data silos, realizes the protection of data privacy, and provides capabilities such as joint data analysis and joint data modeling.

[0029] The present invention proposes a new technology for conducting security analysis and calculation of data under the premise of ensuring that data is not leaked, emphasizing that data is "available but not visible" and "known but not recognized" during the circulation process.

[0030] The present invention provides a variety of privacy protection mechanisms, including homomorphic encryption, secret sharing, differential privacy, trusted execution environment, etc. The centralized architecture can avoid the risk of single-point privacy leakage, meet the data analysis and mining process of multiple subjects based on business needs, and use external data to complete the governance and improvement of own data, information expansion and other needs. Description of the drawings:

[0031] Figure 1 This is a schematic diagram of a data security sharing system in a non-trusted environment according to the present invention. Specific implementation method:

[0032] In order to make the purpose, technical scheme and advantages of the present invention clearer, the technical scheme of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. The embodiments described in this application are only part of the embodiments of the present invention, not all of them. Based on the spirit of the present invention, other embodiments obtained by ordinary technicians in this field without creative work are all within the scope of protection of the present invention.

[0033] like Figure 1 As shown, the present invention proposes a data security sharing system in a non-trusted environment, and the system mainly includes two parts: a central platform system and a front-end system.

[0034] The central platform system is deployed in a third-party trusted cloud. The front-end system is deployed in the internal security area of ​​each data owner. The central platform system is responsible for communicating with the front-end systems deployed in the intranet of each business party and for data transfer processing. Functions include communication with the client service network, task scheduling, data processing, and background management. The central platform system and the client use two-way login authentication to ensure information security. That is, when the client initiates a request and calls the central end, it needs to carry the central end token authentication information. When the central end calls the client, it also needs to carry the client authentication token. At the same time, a dedicated line is established between the central end and the client, and network communication is carried out through the https protocol.

[0035] The client includes the front-end system and the client system. The front-end system serves as the connection intermediary system between the central platform and the client system.

[0036] The central platform system and the front-end processor use a dedicated line with TLS encryption for communication. The central platform and the front-end processor use signatures to prevent parameters from being tampered with or intercepted.

[0037] sign: used for parameter signature to prevent illegal tampering of parameters. The value of sign includes non-empty parameters in ascending order + token + key + timestamp (current timestamp) + nonce (a combination of numbers and letters, a 6-bit random number), which are concatenated together and encrypted using MD5. It is passed as a parameter sign in the interface. Before the server calls the interface, it will recalculate the value of sign according to the sign rule and compare it with the value of the sign parameter passed by the interface. If they are equal, it means that the parameter value has not been tampered with. If they are not equal, it means that the parameter has been illegally tampered with and the interface will not be executed.

[0038] timestamp: Timestamp is the current timestamp corresponding to the client calling the interface. Timestamp is used to prevent DoS attacks. Each time the interface is called, the interface will determine the difference between the current system time of the server and the timestamp passed in the interface. If the difference exceeds a certain set time (set to 5 minutes), then the request will be intercepted. The timestamp mechanism can only reduce the time of DoS attacks and shorten the attack time. If the timestamp value is modified manually, it can be handled through the sign signature mechanism.

[0039] The central platform system manages client user information, call log records, and data analysis and auditing. Each of the multiple systems has an independent account, which is registered on the central end. The central end uses tokens to identify user information, record client operation logs, request parameters, information obtained, and record interface logs in detail.

[0040] Data owners such as State Grid Corporation, government, and banks all have their own front-end systems, which run in their own intranet environments. The front-end systems include functions such as user management, message logging, and result caching.

[0041] The data security sharing method in a non-trusted environment of the present invention comprises the following steps:

[0042] S1: The front-end system is deployed in the internal security area of ​​each data owner. The system is connected to the internal application system. The front-end system and the internal application system use access tokens for identity authentication.

[0043] Token is used to identify the identity and credentials of the interface caller, reducing the number of times the username and password are transmitted.

[0044] S2: Deploy the central platform system in a third-party trusted cloud. The central system is responsible for communicating with the front-end systems deployed in the intranet of each business party and for data transfer processing.

[0045] The network communication between the central system and the front-end system uses https encrypted transmission. Https is composed of HTTP+SSL / TLS, that is, a module for processing encrypted information is added to HTTP. Information transmission between the server and the client is encrypted through TLS, so the transmitted data is encrypted data. Digital certificates are used to ensure that the communication data is sent to the correct recipient. Symmetric encryption is used to ensure that the data is not eavesdropped during the communication process.

[0046] The front-end system and the central end system use access tokens for identity authentication. Tokens are used to identify the identity and credentials of the interface caller, reducing the number of times the username and password are transmitted.

[0047] The front-end system needs to apply for an account for interface calling from the central system first. The central system will provide an appId and a key. The key is used for parameter signing to prevent leakage.

[0048] S3: The data demander initiates a request to the front-end system and carries the data that needs to be calculated.

[0049] S4: After receiving the request, the front-end system encrypts the data carried using AES encryption technology and encrypts the AES key using the RSA public key. After completion, the AES encrypted value is placed in the custom request header. The front-end sends a request to the central platform and carries the encrypted data.

[0050] S5: When the request is submitted for the first time, the sign is saved as a key in redis and a timeout is set. The timeout is the same as the difference set in Timestamp. When the same request is accessed for the second time, redis will be checked to see if the sign exists. If it exists, it proves that it has been submitted repeatedly, and the interface will no longer be called. If the sign is deleted in the cache server due to expiration, the difference between the system time and the timestamp passed in the interface will also exceed the set time (5 minutes), and the interface will no longer be called.

[0051] The central platform obtains the customized request header value, uses the RSA private key to decrypt and obtain the AES key, decrypts the parameter data with the AES key, and puts the data into a temporary database.

[0052] S6: The central platform system sends data query instructions to the data owner's front-end machine through established business logic and parameter conditions, and uses the AES key of the data owner's front-end machine system to encrypt the parameters.

[0053] S7: After receiving the request from the central platform, the data owner's front-end system decrypts the parameters using the AES key, and after decryption, sends a data request to the internal application system based on the parameter conditions. After obtaining the internal application system data, the data is encrypted using the AES key, and then the AES key is encrypted using the RSA public key and placed in the custom request header. After completion, the data owner's front-end sends the data to the central platform.

[0054] S8: After receiving the data, the central platform uses the RSA private key to decrypt the request header to obtain the AES key, and then uses the AES key to decrypt the data. Through the actual business logic, it calculates with the data provided by the data demander to obtain the required results. The result is encrypted using the AES key of the data demander's front-end and returned to the data demander's front-end.

[0055] S9: After receiving the data from the center, use the AES key to decrypt the data and return the result to the client system.

[0056] S10: After data delivery is completed, the central platform clears all acquired data and does not save any data.

[0057] In order to make the purpose, technical scheme and advantages of the present invention clearer, the technical scheme of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. The embodiments described in this application are only part of the embodiments of the present invention, not all of them. Based on the spirit of the present invention, other embodiments obtained by ordinary technicians in this field without creative work are all within the scope of protection of the present invention.

Claims

1. A method for secure data sharing in an untrusted environment. It is characterized in that The method comprises the following steps: S1: Deploy the front-end system in the internal security area of ​​each data owner; S2: Deploy the central platform system in a third-party trusted cloud; S3: The data demander initiates a request to the front-end system and carries the data that needs to be calculated; S4: After receiving the request, the front-end system encrypts the data using AES encryption technology and uses the RSA public key to encrypt the AES key. After completion, the AES encrypted value is placed in the custom request header. S5: The front-end sends a request to the central platform, carrying the encrypted data; S6: The central platform obtains the custom request header value, uses the RSA private key to decrypt and obtain the AES key, decrypts the parameter data using the AES key, and puts the data into a temporary database; S7: The central platform system sends a data query instruction to the data owner's front-end processor according to the established business logic and parameter conditions, and uses the AES key of the data owner's front-end processor system to encrypt the parameters; S8: After receiving the request from the central platform, the front-end system of the data owner decrypts the parameters using the AES key, and after decryption, sends a data request to the internal application system based on the parameter conditions; S9: After the data owner's front-end system obtains the internal application system data, it uses the AES key to encrypt the data, and then uses the RSA public key to encrypt the AES key and put it into the custom request header. After completion, the data owner's front-end system sends the data to the central platform; S10: After receiving the data, the central platform system uses the RSA private key to decrypt the request header to obtain the AES key, and then uses the AES key to decrypt the data. Through the actual business logic, it calculates with the data provided by the data demander to obtain the required results, and uses the AES key of the data demander's front-end to encrypt the results and return them to the data demander's front-end. S11: After receiving the data from the center, the front-end of the data demander uses the AES key to decrypt the data and returns the result to the customer system; S12: After the data delivery is completed, the central platform system clears all acquired data and does not save any data.

2. A data security sharing system in a non-trusted environment, used to implement the data security sharing method as claimed in claim 1, It is characterized in that The system includes a central platform system and a front-end system; the central platform system is responsible for communicating and data transfer processing with each front-end system, and the front-end system serves as a connection intermediary system between the central platform system and the client system; the central platform system and the front-end system use two-way login authentication to ensure information security; that is, the front-end system initiates a request and calls the central platform system, which needs to carry the central platform system token authentication information, and the central platform system calls the front-end system and also needs to carry the client authentication token.

3. The system according to claim 2, It is characterized in that A dedicated line is established between the central platform system and the front-end system, and between the front-end system and the internal application system, and network communication is carried out through the https protocol.

4. The system according to claim 3, It is characterized in that The Https is composed of HTTP+SSL / TLS, that is, a module for processing encrypted information is added to HTTP.

5. The system according to claim 4, It is characterized in that The central platform system and the front-end system use signatures for access to prevent parameters from being tampered with or intercepted.

6. The system according to claim 5, It is characterized in that The value of the signature includes non-empty parameters in ascending order, token authentication, verification code, current timestamp, and random password spliced ​​together; the random password includes a combination of numbers and letters, a 6-digit random number, encrypted using MD5, and passed in front of a parameter in the interface.

7. The system according to claim 6, It is characterized in that Before the server calls the interface, it will recalculate the previous value according to the signature rules and then compare it with the value of the signature parameter passed by the interface. If they are equal, it means that the parameter value has not been tampered with. If they are not equal, it means that the parameter has been illegally tampered with and the interface will not be executed.

8. The system according to claim 7, It is characterized in that The timestamp is the current timestamp corresponding to when the client calls the interface. Each time the interface is called, the interface will determine the difference between the current system time of the server and the timestamp passed in the interface. If the difference exceeds the preset time, the request will be intercepted.

Images