Sensitive data transmission method and device and computer readable storage medium
By determining the target sensitive fields in sensitive data transmission and encrypting, the problems of data leakage and unauthorized access during transmission are solved, achieving higher data security and effectiveness of authorized access.
Patent Information
- Application Number
- CN202411939088.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-26
- Publication Date
- 2025-05-06
AI Technical Summary
When transmitting sensitive data, the prior art has the risk of data leakage and unauthorized access, making it difficult to effectively protect the security of sensitive data.
By receiving file requests from the requesting party, the target sensitive fields are determined and the fields are encrypted using an authorization key, while other sensitive fields are encrypted in one-way manner, ensuring that only authorized requesting parties can decrypt sensitive data.
It effectively improves the security of sensitive data transmission, ensures that only authorized requesters can access sensitive data, and reduces the risk of data breaches and unauthorized access.
Smart Images

Figure CN119945734A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of data processing technology, and in particular, to a sensitive data transmission method, device, and computer-readable storage medium. Background Art
[0002] In today's information and digital age, with the popularization of data exchange and communication, how to effectively protect the security of sensitive data has become a key issue that needs to be solved urgently. Especially in the transmission process of sensitive information such as personal privacy, financial data, medical records, etc., the risk of data leakage and unauthorized access is increasing. Therefore, data security and privacy protection have become technical problems in all walks of life.
[0003] In the prior art, the administrator manages the data. When the data requester needs to access certain sensitive information in the data, he will apply to the administrator, and the administrator will decrypt the sensitive information and then transmit the data to the requester. However, if the administrator transmits the decrypted output to the requester and it is intercepted by a third party, the sensitive data will be leaked and security will be threatened. Summary of the invention
[0004] The embodiments of the present application provide a sensitive data transmission method, device and computer-readable storage medium, which can improve the security when transmitting sensitive data.
[0005] A first aspect of an embodiment of the present application provides a sensitive data transmission method, including:
[0006] Receiving a file request sent by a requesting party to obtain a target file;
[0007] Determine a target sensitive field according to the file request, where the target sensitive field is a sensitive field within the authorization scope of the requesting party;
[0008] Encrypting the target sensitive field using an authorization key, and performing one-way encryption on other sensitive fields in the target file, wherein the requesting party has the authorization key pre-stored locally;
[0009] The encrypted target file is sent to the requesting party, so that the requesting party uses the locally pre-stored authorization key to decrypt the target sensitive field.
[0010] Optionally, determining a target sensitive field according to the file request includes:
[0011] Parsing the file request to obtain a token in the file request;
[0012] The token is used to query the database to determine the target sensitive field.
[0013] Optionally, after parsing the file request to obtain a token in the file request, the method further includes:
[0014] Determine the authorization key associated with the token.
[0015] Optionally, before receiving the file request sent by the requesting party to obtain the target file, the method further includes:
[0016] Receiving an authorization request sent by a requester, wherein the authorization request includes a request authorization field;
[0017] Determining whether the requested authorization field is within the field that requires plain text pre-registered by the requesting party;
[0018] If yes, determining the target sensitive field from the requested authorization field;
[0019] Generate a token for the requester according to the target sensitive field, and generate a random authorization key;
[0020] Associating the token with the authorization key;
[0021] Send the token and the authorization key to the requester.
[0022] Optionally, before receiving the authorization request sent by the requester, the method further includes:
[0023] The pre-registration information sent by the requesting party is received, wherein the pre-registration information includes the fields that need to be in plain text and are pre-registered by the requesting party.
[0024] Optionally, after receiving the pre-registration information sent by the requesting party, the method further includes:
[0025] generating a registration identifier according to the pre-registration information;
[0026] Sending the registration identifier to the requesting party;
[0027] The determining whether the authorization request field is within the field that requires plain text and that is pre-registered by the requesting party comprises:
[0028] Obtaining the registration identifier from the authorization request;
[0029] Acquiring pre-registration information according to the registration identifier;
[0030] It is determined according to the pre-registration information whether the authorization request field is within the field requiring plain text pre-registered by the requesting party.
[0031] Optionally, after generating a registration identifier according to the pre-registration information, the method further includes:
[0032] generating a session key for the requesting party;
[0033] The sending the registration identifier to the requesting party comprises:
[0034] sending the registration identifier and the session key to the requesting party;
[0035] The receiving authorization request sent by the requesting party includes:
[0036] receiving an authorization request encrypted by the requesting party using the session key;
[0037] Decrypting the authorization request using the authorization key to obtain a decrypted authorization request;
[0038] The sending the token and the authorization key to the requesting party includes:
[0039] Encrypting the token and the authorization key using the session key;
[0040] Send the encrypted token and the authorization key to the requester.
[0041] A second aspect of an embodiment of the present application provides a sensitive data transmission device, including:
[0042] A first receiving unit, configured to receive a file request sent by a requesting party to obtain a target file;
[0043] A first determining unit, configured to determine a target sensitive field according to the file request, wherein the target sensitive field is a sensitive field within an authorization scope of the requesting party;
[0044] An encryption unit, used to encrypt the target sensitive field using an authorization key, and to perform one-way encryption on other sensitive fields in the target file, wherein the requesting party has the authorization key pre-stored locally;
[0045] The sending unit is used to send the encrypted target file to the requesting party, so that the requesting party uses the locally pre-stored authorization key to decrypt the target sensitive field.
[0046] Optionally, the encryption unit is specifically used for:
[0047] Parsing the file request to obtain a token in the file request;
[0048] The token is used to query the database to determine the target sensitive field.
[0049] Optionally, the device further comprises:
[0050] The second determining unit is used to determine, according to the token, an authorization key associated therewith.
[0051] Optionally, the device further includes an authorization key unit, and the authorization key unit includes:
[0052] A receiving module, configured to receive an authorization request sent by a requesting party, wherein the authorization request includes a request authorization field;
[0053] A judgment module, used for judging whether the authorization request field is within the field requiring plain text pre-registered by the requesting party;
[0054] a determination module, configured to determine a target sensitive field from the request authorization field when the judgment module determines that the request authorization field is within the field that needs to be in plain text and pre-registered by the requester;
[0055] A generation module, used to generate a token for the requester according to the target sensitive field, and generate a random authorization key;
[0056] An association module, used to associate the token with the authorization key;
[0057] A sending module is used to send the token and the authorization key to the requesting party.
[0058] Optionally, the device further comprises:
[0059] The second receiving unit is used to receive the pre-registration information sent by the requesting party, wherein the pre-registration information includes the fields that need to be in plain text and are pre-registered by the requesting party.
[0060] Optionally, the device further includes a registration unit, wherein the registration unit is used to:
[0061] generating a registration identifier according to the pre-registration information;
[0062] Sending the registration identifier to the requesting party;
[0063] The judgment module is specifically used for:
[0064] Obtaining the registration identifier from the authorization request;
[0065] Acquiring pre-registration information according to the registration identifier;
[0066] It is determined according to the pre-registration information whether the authorization request field is within the field requiring plain text pre-registered by the requesting party.
[0067] Optionally, the device further comprises:
[0068] A session key unit, used to generate a session key for the requesting party;
[0069] The registration unit is specifically used for:
[0070] sending the registration identifier and the session key to the requesting party;
[0071] The receiving module is specifically used for:
[0072] receiving an authorization request encrypted by the requesting party using the session key;
[0073] Decrypting the authorization request using the authorization key to obtain a decrypted authorization request;
[0074] The sending module is specifically used for:
[0075] Encrypting the token and the authorization key using the session key;
[0076] Send the encrypted token and the authorization key to the requester.
[0077] A third aspect of the embodiments of the present application provides a sensitive data transmission device, including:
[0078] Processor, memory, input-output unit, and bus;
[0079] The processor is connected to the memory, the input and output unit, and the bus;
[0080] A program is stored in the memory, and the processor calls the program to execute the method in the first aspect and any possible implementation manner of the first aspect.
[0081] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, on which a program is stored. When the program is executed on a computer, the computer executes the method in the first aspect and any possible implementation of the first aspect.
[0082] It can be seen from the above technical solutions that this application has the following advantages:
[0083] This application effectively ensures the security of sensitive information in the file. Sensitive fields are only processed within the scope of authorization of the requester, and encryption technology is used to protect data privacy and prevent information leakage during transmission. In addition, the one-way encryption method for other sensitive fields ensures that even if the data is leaked, it cannot be abused. Ultimately, only authorized requesters can decrypt sensitive fields, thereby reducing the risk of data leakage and ensuring the effectiveness of authorized access. BRIEF DESCRIPTION OF THE DRAWINGS
[0084] Figure 1 A flowchart of an embodiment of a sensitive data transmission method in an embodiment of the present application;
[0085] Figure 2 A schematic diagram of a flow chart of an embodiment of determining a target sensitive field in an embodiment of the present application;
[0086] Figure 3 A schematic diagram of a process for generating an authorization key in an embodiment of the present application;
[0087] Figure 4 A schematic diagram of a process for generating a registration mark in an embodiment of the present application;
[0088] Figure 5 A flowchart of an embodiment of the present application for determining whether a request authorization field is within a field that is pre-registered by the requesting party and requires plain text;
[0089] Figure 6 This is a schematic diagram of the structure of an embodiment of a sensitive data transmission device in an embodiment of the present application;
[0090] Figure 7 It is a structural schematic diagram of another embodiment of the sensitive data transmission device in the embodiment of the present application. DETAILED DESCRIPTION
[0091] The embodiments of the present application provide a sensitive data transmission method, device and computer-readable storage medium for improving the security when transmitting sensitive data.
[0092] The method of the present application can be applied to a server, a terminal or other devices with logic processing capabilities, and the present application does not limit this. For the convenience of description, the following description is made by taking the execution subject as a server as an example.
[0093] The embodiments of the present application will be described below in conjunction with the accompanying drawings.
[0094] See also Figure 1 In the embodiments of the present application, one embodiment of the sensitive data transmission method includes:
[0095] 101. Receive a file request sent by a requesting party to obtain a target file;
[0096] The server first receives a file request from the requester. This request usually includes the file identifier, the identity information of the requester, and a request for specific file content. The server needs to ensure that the identity and authority of the requester are verified to ensure that the file request is legal and meets the relevant authorization requirements.
[0097] 102. Determine the target sensitive field according to the file request, where the target sensitive field is a sensitive field within the authorization scope of the requesting party;
[0098] After receiving the file request, the server identifies the sensitive fields in the target file based on the specific content of the request. Sensitive fields are those that contain personal or confidential information. The server needs to confirm whether these fields are within the authorization scope of the requester. The authorization scope is usually determined by the identity of the requester, the permission level, and the prior authorization settings. If the authorization scope of the requester allows access to these sensitive fields, the server will continue processing; otherwise, the server will reject the request or take appropriate protection measures.
[0099] 103. Use the authorization key to encrypt the target sensitive field and perform one-way encryption on other sensitive fields in the target file. The requesting party has the authorization key pre-stored locally.
[0100] After determining the target sensitive field, the server uses the locally stored authorization key to encrypt the target sensitive field to ensure that sensitive information is not accessed by unauthorized third parties during transmission. The authorization key is a symmetric key that is held by both the server and the requester. The server uses its own key to encrypt sensitive fields to ensure that these fields remain confidential during transmission. At the same time, for other sensitive fields in the file, the server uses a one-way encryption method (such as hashing) to encrypt these fields, which are converted into an irreversible data format to prevent data leakage or abuse. In this way, even if the data is leaked, the original data cannot be restored.
[0101] 104. Send the encrypted target file to the requester, so that the requester uses the authorization key pre-stored locally to decrypt the target sensitive field.
[0102] Once the encryption operation is completed, the server sends the encrypted file to the requester. The requester can use the authorization key pre-stored locally to decrypt the target sensitive field and recover the sensitive information in the file. Since the encryption of the target sensitive field is based on the authorization key, only the requester with the correct key can successfully decrypt and view these sensitive contents.
[0103] In this embodiment, the server effectively ensures the security of sensitive information in the file. Sensitive fields are processed only within the scope of authorization of the requester, and encryption technology is used to protect data privacy and prevent information leakage during transmission. In addition, the one-way encryption method for other sensitive fields ensures that even if the data is leaked, it cannot be abused. Ultimately, only authorized requesters can decrypt sensitive fields, thereby reducing the risk of data leakage and ensuring the effectiveness of authorized access.
[0104] See also Figure 2 In some embodiments of the present application, step 102 in the above embodiment determines the target sensitive field according to the file request, and may include the following steps:
[0105] 201. Parse the file request to obtain the token in the file request;
[0106] After receiving the file request, the server first parses the request content and extracts the token in the file request. The token is an identifier generated by the server for the requester, which is used to prove the identity of the requester and determine its access rights. The parsing process ensures that the token is accurately extracted from the request for subsequent identity authentication and permission checks.
[0107] 202. Use the token to query the database to determine the target sensitive field.
[0108] After obtaining the token, the server uses the token to query the database. The database stores the authorization information associated with each token, including the target files that the requester can access and the sensitive fields therein. By querying the database, the server can determine the specific sensitive fields that the requester is authorized to access so that the file can be processed accordingly. This step ensures that only authorized sensitive fields are passed to the requester, while other sensitive information is protected.
[0109] Furthermore, after step 202, the following steps may be further included:
[0110] 203. Determine the authorization key associated with the token.
[0111] The server can further determine the authorization key associated with the token based on the token. Each token corresponds to a specific authorization key, which is used to encrypt or decrypt sensitive fields. By looking up the authorization key associated with the token in the database, the server can ensure that the encryption operation uses the correct key, thereby ensuring the security and integrity of sensitive data.
[0112] In this embodiment, the server can accurately determine the identity of the requester and its access rights based on the token, ensuring that only authorized sensitive fields are returned to the requester. At the same time, it can confirm the correctness of the authorization key, ensure the security and accuracy of encryption and decryption operations on sensitive fields, prevent unauthorized access and data leakage, and improve the security and reliability of data transmission.
[0113] See also Figure 3 In some embodiments of the present application, before step 101 in the above embodiment receives a file request for obtaining a target file sent by a requesting party, the following steps may be further included:
[0114] 301. Receive an authorization request sent by a requester, where the authorization request includes a request authorization field;
[0115] The server receives the authorization request sent by the requester, which contains the request authorization field. The request authorization field is usually an identifier of the sensitive information that the requester wants to access. The server needs to effectively parse the request and determine the legitimacy of the request. This step prepares for subsequent permission verification and key management.
[0116] 302. Determine whether the authorization request field is within the field that needs to be in plain text and pre-registered by the requesting party; if so, execute step 303;
[0117] The server determines whether the requested authorization field is a field that the requester has pre-registered and needs to be transmitted in plain text. If the requested authorization field is a field that the requester has registered and can be transmitted in plain text, the server will execute step 303 for further processing. This judgment ensures that the requester has access control over sensitive fields, and only authorized fields will be further processed.
[0118] 303. Determine the target sensitive field from the request authorization field;
[0119] If it is determined that the request authorization field is a field that the requester has registered and can be transmitted in plain text, the server selects some or all sensitive fields from the request authorization field as the target sensitive fields, rather than directly authorizing the requester with the request authorization field. The server administrator limits the scope of the request authorization field based on its own internal regulations, policies, or relevant laws and regulations. Even if the request authorization field itself contains multiple sensitive information items, the server will only select some sensitive fields that are allowed to be disclosed or authorized for access according to regulations or legal requirements to ensure compliance and data protection requirements. This screening process can prevent the requester from obtaining unauthorized information, thereby avoiding potential legal risks or security risks.
[0120] 304. Generate a token for the requester based on the target sensitive field and generate a random authorization key;
[0121] The server generates a unique token based on the determined target sensitive field to identify the authorization status of the requester. At the same time, the server also generates a random authorization key for encrypting or decrypting the target sensitive field. This key ensures the security of each authorization request and prevents the key from being maliciously reused. It should be noted that the server can generate authorization keys in a variety of ways, such as AES, DES, 3DES, Blowfish, Twofish, etc., which are not limited in this application.
[0122] 305. Associate the token with the authorization key;
[0123] After generating the token and authorization key, the server associates the two. This association ensures that each token corresponds to a specific authorization key, so that when the requester uses the token, it can use the corresponding key for decryption or encryption operations. This step ensures the orderliness and security of key management.
[0124] 306. Send the token and authorization key to the requester.
[0125] Finally, the server sends the generated token and authorization key to the requester. After receiving these two pieces of information, the requester can use the authorization key to perform subsequent encryption or decryption operations to access the target sensitive fields. This step ensures that the requester can correctly handle sensitive data related to the authorization key and maintain the confidentiality of the data.
[0126] In this embodiment, the server can effectively manage the access rights of the requester and provide a secure authorization mechanism for the requester, so as to control the scope of sensitive data permissions. Moreover, the generation of tokens and random authorization keys ensures the uniqueness and confidentiality of each request, and only the requester holding the correct token can access the sensitive fields related to it. By controlling the requester's access to sensitive data, the data protection capability is enhanced and the risk of data leakage and abuse is reduced.
[0127] See also Figure 4 and Figure 5 In some embodiments of the present application, before step 101 in the above embodiment receives a file request for obtaining a target file sent by a requesting party, the following steps may be further included:
[0128] 401. Receive pre-registration information sent by the requesting party, where the pre-registration information includes the fields that need to be in plain text and that are pre-registered by the requesting party;
[0129] The server receives the pre-registration information sent by the requester. The pre-registration information includes the fields that the requester wants to be public or transmitted in plain text. Through this information, the server can identify the fields that the requester has selected and allows for plain text transmission. These fields may contain some non-sensitive information or authorized fields, and the server will perform subsequent processing based on these fields.
[0130] It should be noted that when the requesting party sends the pre-registration information to the server, it can send it by accessing the server online, or submit the materials related to the pre-registration information to the server administrator offline, and the server administrator will input the pre-registration information into the server. This application does not limit this.
[0131] 402. Generate a registration mark according to the pre-registration information;
[0132] After receiving the pre-registration information, the server generates a unique registration identifier based on the content. The registration identifier is used to identify the pre-registration information of the requester and is associated with the requester's permissions and the selected plaintext field. The registration identifier ensures that the server can quickly verify the requester's pre-registration information in subsequent operations and is used to identify the requester's authorization status for access to specific data.
[0133] 403. Send a registration identifier to the requesting party;
[0134] Finally, the server sends the generated registration identifier to the requester. The requester can use this registration identifier to reference the plaintext field that it pre-registered. In future requests, the server uses this identifier to verify the requester's identity and its access rights to the field.
[0135] At this time, step 302 in the above embodiment determines whether the authorization request field is within the field that needs to be in plain text pre-registered by the requesting party, and may include the following steps:
[0136] 3021. Obtain the registration identifier from the authorization request;
[0137] The server extracts the registration ID from the authorization request sent by the requester. The authorization request usually contains the field information that the requester wants to access, and the registration ID identifies the pre-registration status of the requester. The registration ID is a unique identifier generated by the server to ensure that the server can identify the authorization scope of the requester and its access rights to specific fields.
[0138] 3022. Obtain pre-registration information according to the registration identifier;
[0139] After obtaining the registration identifier, the server retrieves the corresponding pre-registration information from the database or storage system according to the identifier. The pre-registration information includes the fields that the requester has pre-registered and allows for plain text transmission. This information helps the server determine which fields can be accessed by the requester in plain text and which fields require additional protection measures or encryption to ensure data security.
[0140] 3023. Determine, based on the pre-registration information, whether the authorization request field is within the field that requires plain text and that is pre-registered by the requesting party.
[0141] The server determines whether the requested authorization field belongs to the field that the requester has registered and needs to be transmitted in plain text based on the field list obtained from the pre-registration information. If the requested authorization field is within the pre-registered field range, the server will allow the request to continue to be processed and perform further operations according to the authorization rules. If it is not within the registered range, the server will reject the request or take appropriate protection measures, such as encrypting the field to ensure data security.
[0142] In this embodiment, the server can effectively manage the pre-registration information of the requester, ensuring that the requester can access the predetermined plaintext field only under authorization. The registration identification is generated and sent to the requester, ensuring that both parties can perform effective identity authentication and field access control based on the identification in subsequent interactions. This can reduce the risk of erroneous access and improper use of data, and also improve the clarity and security of data access management.
[0143] At the same time, it ensures that the server accurately identifies the pre-registered access rights of the requester based on the registration ID of the requester, thereby controlling which fields can be accessed in plain text and which need to be encrypted or protected. This mechanism effectively prevents the requester from accessing sensitive information that should not be made public, ensures the security and compliance of data, and reduces the risk of data leakage or abuse.
[0144] Furthermore, in some embodiments of the present application, after 402 in the above embodiment, generating a registration identifier according to the pre-registration information, the step of: generating a session key for the requesting party may also be included.
[0145] After generating the registration identifier, the server also generates a session key for the requester. The session key is a temporary symmetric encryption key used to ensure the security of data during the session. The key is used to encrypt the authorization request sent by the requester and the response data sent by the server, thereby protecting the confidentiality and integrity of the data during the interaction between the two parties. It should be noted that the server can generate session keys in a variety of ways, such as AES, DES, 3DES, Blowfish, Twofish, etc., which are not limited in this application.
[0146] At this time, step 403 in the above embodiment of sending the registration identifier to the requesting party may include the step of sending the registration identifier and the session key to the requesting party.
[0147] When sending the registration ID, the server not only sends the registration ID to the requester, but also sends the session key generated for the requester. After receiving these two pieces of information, the requester can use the session key to encrypt the authorization request to ensure the security of the request data during transmission.
[0148] In the above embodiment, step 301 of receiving the authorization request sent by the requesting party may include the steps of: receiving the authorization request encrypted by the requesting party using the session key; decrypting the authorization request using the authorization key to obtain the decrypted authorization request.
[0149] When the server receives the authorization request sent by the requester, the authorization request is encrypted with the session key. The server first decrypts the request with the authorization key to restore the original authorization request content. The session key is only used to protect the security of the request during transmission, while the authorization key is used to decrypt and verify the legitimacy of the request.
[0150] In the above embodiment, step 306, sending the token and authorization key to the requesting party, may include the steps of: encrypting the token and authorization key using the session key; and sending the encrypted token and authorization key to the requesting party.
[0151] After generating the token and authorization key, the server will encrypt the two pieces of information using the session key. The encrypted token and authorization key are sent to the requester to ensure that they will not be stolen or tampered with by a third party during transmission. After receiving the encrypted information, the requester uses the session key to decrypt it and obtain the token and authorization key that can be used for subsequent operations.
[0152] By generating and using session keys, data transmission between the requester and the server is more secure. Session key encryption can effectively protect the content of the authorization request and the server response, avoiding potential man-in-the-middle attacks or data leaks. In addition, the combination of session keys and authorization keys enhances the multi-level security of data protection, thereby improving the overall security and protection capabilities of the system.
[0153] See also Figure 6 In the embodiments of the present application, one embodiment of the sensitive data transmission device includes:
[0154] The first receiving unit 501 is used to receive a file request sent by a requesting party to obtain a target file;
[0155] A first determining unit 502 is used to determine a target sensitive field according to the file request, where the target sensitive field is a sensitive field within the authorization scope of the requesting party;
[0156] The encryption unit 503 is used to encrypt the target sensitive field using the authorization key and to perform one-way encryption on other sensitive fields in the target file. The requesting party has the authorization key pre-stored locally.
[0157] The sending unit 504 is used to send the encrypted target file to the requesting party, so that the requesting party uses the locally pre-stored authorization key to decrypt the target sensitive field.
[0158] The embodiments of the present application effectively ensure the security of sensitive information in the file. Sensitive fields will only be processed within the scope of authorization of the requesting party, and encryption technology is used to protect data privacy and prevent information leakage during transmission. In addition, the processing of other sensitive fields by the one-way encryption method ensures that even if the data is leaked, it cannot be abused. Ultimately, only the authorized requesting party can decrypt the sensitive fields, thereby reducing the risk of data leakage and ensuring the effectiveness of authorized access.
[0159] Optionally, the encryption unit 503 is specifically used for:
[0160] Parse the file request to obtain the token in the file request;
[0161] Use the token to query the database to determine the target sensitive fields.
[0162] Optionally, the device further comprises:
[0163] The second determining unit is used to determine, according to the token, an authorization key associated therewith.
[0164] Optionally, the device further includes an authorization key unit, and the authorization key unit includes:
[0165] A receiving module, used for receiving an authorization request sent by a requester, wherein the authorization request includes a request authorization field;
[0166] A judgment module, used to judge whether the authorization request field is within the field that needs to be in plain text and pre-registered by the requesting party;
[0167] A determination module, configured to determine a target sensitive field from the request authorization field when the judgment module determines that the request authorization field is within the field that needs to be in plain text pre-registered by the requester;
[0168] The generation module is used to generate a token for the requester based on the target sensitive field and generate a random authorization key;
[0169] The association module is used to associate the token with the authorization key;
[0170] The sending module is used to send the token and authorization key to the requester.
[0171] Optionally, the device further comprises:
[0172] The second receiving unit is used to receive the pre-registration information sent by the requesting party, where the pre-registration information includes the fields that need to be in plain text and are pre-registered by the requesting party.
[0173] Optionally, the device further includes a registration unit, and the registration unit is used to:
[0174] Generate a registration mark according to the pre-registration information;
[0175] Sending a registration identifier to the requesting party;
[0176] The judgment module is specifically used for:
[0177] Get the registration ID from the authorization request;
[0178] Obtain pre-registration information according to the registration identifier;
[0179] It is determined based on the pre-registration information whether the authorization request field is within the field that needs to be in plain text and that is pre-registered by the requester.
[0180] Optionally, the device further comprises:
[0181] A session key unit, used to generate a session key for the requesting party;
[0182] The registration unit is specifically used for:
[0183] Sending a registration identifier and a session key to the requesting party;
[0184] The receiving module is specifically used for:
[0185] receiving the authorization request encrypted by the requester using the session key;
[0186] Decrypt the authorization request using the authorization key to obtain a decrypted authorization request;
[0187] The sending module is specifically used for:
[0188] Use the session key to encrypt the token and authorization key;
[0189] Send the encrypted token and authorization key to the requester.
[0190] In this implementation, the functions of each unit and module are the same as those described above. Figures 1 to 5 The steps in the illustrated embodiments correspond to each other and will not be described again here.
[0191] See also Figure 7 Another embodiment of the sensitive data transmission device in the embodiment of the present application includes:
[0192] Processor 601, memory 602, input and output unit 603 and bus 604;
[0193] The processor 601 is connected to the memory 602, the input and output unit 603 and the bus 604;
[0194] The memory 602 stores a program, and the processor 601 calls the program to execute Figures 1 to 5 Steps in the illustrated embodiment.
[0195] In this embodiment, the function of the processor 601 is the same as that of the aforementioned Figures 1 to 5 The steps in the illustrated embodiments correspond to each other and will not be described again here.
[0196] The embodiment of the present application also provides a computer-readable storage medium on which a program is stored. When the program is executed on a computer, the computer executes the aforementioned Figures 1 to 5 A method in any possible implementation.
[0197] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0198] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0199] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0200] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0201] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.
Claims
1. A sensitive data transmission method, characterized in that: include: Receiving a file request sent by a requesting party to obtain a target file; Determine a target sensitive field according to the file request, where the target sensitive field is a sensitive field within the authorization scope of the requesting party; Encrypting the target sensitive field using an authorization key, and performing one-way encryption on other sensitive fields in the target file, wherein the requesting party has the authorization key pre-stored locally; The encrypted target file is sent to the requesting party, so that the requesting party uses the locally pre-stored authorization key to decrypt the target sensitive field.
2. The method according to claim 1, characterized in that Determining the target sensitive field according to the file request includes: Parsing the file request to obtain a token in the file request; The token is used to query the database to determine the target sensitive field.
3. The method according to claim 2, characterized in that After parsing the file request to obtain a token in the file request, the method further includes: Determine the authorization key associated with the token.
4. The method according to claim 2 or 3, characterized in that: Before receiving the file request sent by the requesting party to obtain the target file, the method further includes: Receiving an authorization request sent by a requester, wherein the authorization request includes a request authorization field; Determining whether the requested authorization field is within the field that requires plain text pre-registered by the requesting party; If yes, determining the target sensitive field from the requested authorization field; Generate a token for the requester according to the target sensitive field, and generate a random authorization key; Associating the token with the authorization key; Send the token and the authorization key to the requester.
5. The method according to claim 4, characterized in that Before receiving the authorization request sent by the requesting party, the method further includes: The pre-registration information sent by the requesting party is received, wherein the pre-registration information includes the fields that need to be in plain text and are pre-registered by the requesting party.
6. The method according to claim 5, characterized in that After receiving the pre-registration information sent by the requesting party, the method further includes: generating a registration identifier according to the pre-registration information; sending the registration identifier to the requesting party; The determining whether the authorization request field is within the field that requires plain text and that is pre-registered by the requesting party comprises: Obtaining the registration identifier from the authorization request; Acquiring pre-registration information according to the registration identifier; It is determined according to the pre-registration information whether the authorization request field is within the field requiring plain text pre-registered by the requesting party.
7. The method according to claim 6, characterized in that After generating the registration mark according to the pre-registration information, the method further includes: generating a session key for the requesting party; The sending the registration identifier to the requesting party comprises: sending the registration identifier and the session key to the requesting party; The receiving authorization request sent by the requesting party includes: receiving an authorization request encrypted by the requesting party using the session key; Decrypting the authorization request using the authorization key to obtain a decrypted authorization request; The sending the token and the authorization key to the requesting party includes: Encrypting the token and the authorization key using the session key; Send the encrypted token and the authorization key to the requester.
8. A sensitive data transmission device, characterized in that: include: A first receiving unit, configured to receive a file request sent by a requesting party to obtain a target file; A first determining unit, configured to determine a target sensitive field according to the file request, wherein the target sensitive field is a sensitive field within an authorization scope of the requesting party; An encryption unit, used to encrypt the target sensitive field using an authorization key, and to perform one-way encryption on other sensitive fields in the target file, wherein the requesting party has the authorization key pre-stored locally; The sending unit is used to send the encrypted target file to the requesting party, so that the requesting party uses the locally pre-stored authorization key to decrypt the target sensitive field.
9. A sensitive data transmission device, characterized in that: include: Processor, memory, input-output unit, and bus; The processor is connected to the memory, the input and output unit, and the bus; A program is stored in the memory, and the processor calls the program to execute the method according to any one of claims 1 to 7. 10 . A computer-readable storage medium having a program stored thereon, wherein when the program is executed on a computer, the computer is caused to execute the method according to claim 1 .