A data security protection method and system based on honeypot tracing

Abstract

The application provides a data security protection method and system based on honeypot tracing, relates to the technical field of information security, and comprises the following steps: when target data is stored or queried, an independent key derived by HKDF is used to perform AES-256-GCM encryption on each sensitive field in the target data, so that encrypted data is obtained; based on a session identifier corresponding to a current session, a field name, a user identifier and a server salt, an HMAC-SHA256 operation is performed to generate a unique double-layer honeypot mark, and a display mark in the double-layer honeypot mark is embedded into a shielding area of the sensitive field to generate a honeypot index table; if leaked data related to the encrypted data is detected, the display mark is verified by using a verification mark, if tampering does not occur, a first honeypot desensitization value in the leaked data is obtained, and the honeypot index table is queried through the first honeypot desensitization value to determine the session identifier and the user identifier corresponding to the leaked data.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a data security protection method and system based on honeypot tracing. Background Technology

[0002] In data management systems, the display and protection of sensitive data, such as user identity information and medical records, presents a core challenge: businesses need to display data to authorized users while simultaneously preventing unauthorized access or leakage. However, in current application scenarios, once keys are distributed to clients, the server loses control over the key's lifecycle. Specifically, it cannot proactively revoke distributed keys upon detecting anomalies, cannot limit the key's validity period on the client, and cannot prevent subsequent use after a key leak, making it difficult to promptly stop leaks. Furthermore, existing solutions typically embed tags at the user level or even the table level. The same user sees the same tags in different sessions, making it difficult to guarantee uniqueness in high-concurrency multi-user scenarios. This hinders tracing the source of leaks, and attackers can tamper with the tag values ​​after recognizing the watermark, rendering tracing ineffective and further complicating the process. Summary of the Invention

[0003] In view of this, the present invention proposes a data security protection method and system based on honeypot traceability.

[0004] The technical solution of this invention is implemented as follows: The first aspect of this invention provides a data security protection method based on honeypot tracing, comprising: When performing data entry or query operations on the target data, each sensitive field in the target data is encrypted using an independent key derived from HKDF to obtain encrypted data; Based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session, an HMAC-SHA256 operation is performed to generate a unique double-layer honeypot tag for each sensitive field of the encrypted data. Then, based on the desensitization and masking rules corresponding to the field type of the sensitive field, a display tag from the double-layer honeypot tag is embedded into the masking area of ​​the sensitive field, generating a honeypot index table. The honeypot index table includes multiple specific honeypot desensitization values. The display tag is bound to the session identifier, the field name, and the user identifier. The double-layer honeypot tag also includes a verification tag embedded in the server-side honeypot index table. If leaked data related to the encrypted data is detected, the display tag is verified using the verification tag. If the display tag is determined to be unaltered, the first honeypot desensitization value in the leaked data is obtained, and the honeypot index table is queried using the first honeypot desensitization value to determine the session identifier and user identifier corresponding to the leaked data.

[0005] Based on the above technical solutions, preferably, the step of using an independent key derived from HKDF to encrypt each sensitive field in the target data using AES-256-GCM to obtain encrypted data includes: Retrieve the corresponding master key from the master key registry based on the field name; Using the master key as the input key material, the global random salt as the salt parameter, and the field name as the info parameter, perform HKDF-SHA256 operation to obtain the derived key; Each sensitive field in the target data is encrypted using AES-256-GCM using an independent key composed of the derived key and a random initialization vector to obtain encrypted data.

[0006] Based on the above technical solutions, preferably, the step of performing HMAC-SHA256 operation based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data includes: The session identifier, the field name, and the user identifier are concatenated using a delimiter to obtain a message string. Then, using the server-side encrypted salt as the HMAC key, an HMAC-SHA256 operation is performed to obtain a digest seed. Each byte of the multiple bytes in the summary seed is modulo 10 and mapped to a 0-9 numeric character. The resulting concatenation generates a display marker of the corresponding number of bytes.

[0007] Based on the above technical solutions, preferably, the step of performing HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique two-layer honeypot marker for each sensitive field of the encrypted data further includes: Each byte of the multiple bytes in the summary seed is modulo 36 and mapped to a predefined character set, and then concatenated to generate a verification tag body of the corresponding number of bytes; The verification tag body is concatenated with a preset fixed suffix, and HMAC-SHA256 operation is performed with the server-side encrypted salt as the HMAC key to obtain multiple bytes of the output digest seed. Each byte is then mapped to the predefined character set by taking the modulo 36 to obtain the corresponding verification code. The verification mark body and the check code are concatenated to obtain the complete verification mark.

[0008] Based on the above technical solutions, preferably, after performing HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique double-layer honeypot marker for each sensitive field of the encrypted data, the method further includes: Collision detection is performed on the display tag. If the collision probability is greater than the first threshold, HMAC-SHA256 operation is performed using the server-side encrypted salt as the key to add at least one suffix to the display tag until the collision probability is no greater than the first threshold.

[0009] Based on the above technical solutions, preferably, the desensitization and masking rules corresponding to the field type of the sensitive field embed the display tag in the double-layer honeypot tag into the masking area of ​​the sensitive field to generate a honeypot index table, including: The marker replacement position is determined based on the desensitization and masking rules corresponding to the field type of the sensitive field; The sensitive fields at the designated replacement locations in the target data are replaced with display tags to generate corresponding honeypot desensitization values.

[0010] Based on the above technical solutions, preferably, the honeypot index table includes display markers, verification markers, marker subjects, checksums, collision resolution status, collision resolution rounds, field names, user identifiers, session identifiers, original value hashes, and the generation time of each data item.

[0011] Furthermore, a second aspect of the present invention provides a data security protection system based on honeypot tracing, comprising: a field encryption module, a honeypot marking module, and a data verification module; wherein, The field encryption module is configured to use an independent key derived from HKDF to encrypt each sensitive field in the target data using AES-256-GCM when performing data entry or query operations on the target data, thereby obtaining encrypted data. The honeypot tagging module is configured to perform HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique double-layer honeypot tag for each sensitive field of the encrypted data. Based on the desensitization and masking rules corresponding to the field type of the sensitive field, the module embeds the display tag from the double-layer honeypot tag into the masking area of ​​the sensitive field, generating a honeypot index table. The honeypot index table includes multiple specific honeypot desensitization values. The display tag is bound to the session identifier, the field name, and the user identifier. The double-layer honeypot tag also includes a verification tag embedded in the server-side honeypot index table. The data verification module is configured to, if leaked data related to the encrypted data is detected, verify the display tag using the verification tag, and if it is determined that the display tag has not been tampered with, obtain the first honeypot desensitization value in the leaked data, and query the honeypot index table through the first honeypot desensitization value to determine the session identifier and user identifier corresponding to the leaked data.

[0012] More preferably, a third aspect of the present invention provides an electronic device, including a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements the data security protection method based on honeypot tracing described in the first aspect.

[0013] More preferably, a fourth aspect of the present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the data security protection method based on honeypot tracing described in the first aspect.

[0014] The data security protection method and system based on honeypot tracing of the present invention have the following advantages over the prior art: 1. By using HKDF key derivation, the key management service system stores only a small number of master keys, and field keys are derived on demand without persistence, significantly reducing the key storage scale. Simultaneously, different records use different keys for the same field; a leak of a single field key only affects the corresponding field in that record, not other fields within the same record, reducing the scope of the leak and lowering the risk of a single point of failure causing the overall security system to fail. Furthermore, a two-layer honeypot system is used for tagging. Verification tags are used to verify the displayed tags, ensuring that the displayed tags have not been tampered with. Combining the first honeypot's de-identified value and the honeypot index table in the leaked data, the session identifier and user identifier corresponding to the leaked data are determined, enabling precise tracking and tracing of the leak.

[0015] 2. By employing a two-layer architecture combining the verification tag body and the checksum, along with a collision resolution mechanism, the tag collision problem is eliminated. The verification tag body has a large character space, stored solely in the server-side honeypot index table. Even if duplicate tags are displayed, the unique verification tag can distinguish different session records, resolving the shortcomings of tag collisions and the inability to identify suspects in high-concurrency scenarios. The complete verification tag is accompanied by a checksum generated based on the server-side private salt. During leakage investigation, the checksum can be recalculated and compared to complete the tracing of the leakage behavior.

[0016] 3. By binding the display tag with the session tag, field name, and user tag, after extracting the display tag using the leaked data, the honeypot index table can be directly queried to lock the session tag, field name, and user tag corresponding to the leaked behavior, thereby solving the problem of ambiguous identity tracing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a data security protection method based on honeypot tracing provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a data security protection system based on honeypot tracing provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0020] In some embodiments, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a data security protection method based on honeypot tracing provided in an embodiment of the present invention; the data security protection method based on honeypot tracing provided by the present invention includes: S110, when performing data entry or query operations on the target data, uses an independent key derived from HKDF to encrypt each sensitive field in the target data using AES-256-GCM to obtain encrypted data.

[0021] S120: Based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session, perform HMAC-SHA256 operation to generate a unique double-layer honeypot tag for each sensitive field of the encrypted data. Based on the desensitization and masking rules corresponding to the field type of the sensitive field, embed the display tag in the double-layer honeypot tag into the masking area of ​​the sensitive field to generate a honeypot index table. The honeypot index table includes multiple specific honeypot desensitization values. The display tag is bound to the session identifier, field name, and user identifier. The double-layer honeypot tag also includes a verification tag embedded in the server-side honeypot index table.

[0022] S130, if leaked data related to encrypted data is detected, the display mark is verified using the verification mark. If it is determined that the display mark has not been tampered with, the first honeypot desensitization value in the leaked data is obtained, and the honeypot index table is queried through the first honeypot desensitization value to determine the session identifier and user identifier corresponding to the leaked data.

[0023] In this embodiment, HKDF stands for HMAC-based Key Derivation Function; HMAC stands for Hash-based Message Authentication Code; and SHA-256 represents the 256-bit output of a secure hash algorithm.

[0024] During data import or querying, each sensitive field is encrypted using AES-256-GCM with an independent key derived from the master key via HKDF. When performing import or query operations on target data, the KMS (Key Management Service) maintains only a small number of AES-256 master keys categorized by field, and does not store subkeys for each record. Each master key is generated by a cryptographically secure random number generator (32 bytes) and stored in the master key registry after envelope encryption using HSM or Vault. The master key registry only stores master keys categorized by field type, and its number is constant and does not increase with the number of data records. When it is necessary to encrypt or decrypt a sensitive field of a record, the KMS deterministically derives the field key from the corresponding master key via HKDF-SHA256. The same input always produces the same derived key, therefore, field keys do not need to be persisted. Different records have different keys for the same field, and different fields within the same record have different keys, maintaining field-level isolation.

[0025] The two-layer, separate honeypot tagging architecture relies on session, user, and field triples and the HMAC-SHA256 cryptographic algorithm to generate unique traceability identifiers. It consists of two systems: an externally displayed tag and a backend private verification tag. Collision resolution is used to resolve duplicate conflicts. The tags are then embedded in a desensitized masking area to generate honeypot data, and an index table is established to permanently bind comprehensive traceability information. By replacing the fixed masking symbols in standard desensitization with deterministically derived display tags, the same sensitive data presents different desensitized values ​​in different sessions. Each desensitized value's embedded display tag is bound to the session identifier, field name, and user identifier of that session. Because the display tags are deterministically derived from HMAC-SHA256, the same session identifier, field name, and user identifier input will always produce the same display tag. Therefore, once a specific desensitized value appears in the leaked data, the display tag can be extracted to reverse-check the honeypot index table, precisely locating the specific session and user. Meanwhile, the display markers replace the previously hidden areas, visually matching the normal data format. Authorized internal personnel cannot distinguish which bits are real data and which are honeypot markers, thus achieving covert embedding of traceability markers without affecting the business display effect. Verification markers are stored on the server side, not in the display data. They are used for precise disambiguation when display markers collide, and to detect whether the leaker has intentionally tampered with the display markers. If tampering is detected, the act of tampering itself becomes additional evidence for accountability.

[0026] In some embodiments, each sensitive field in the target data is encrypted using an independent key derived from HKDF using AES-256-GCM to obtain encrypted data, including: Retrieve the corresponding master key from the master key registry based on the field name; Using the master key as the input key material, the global random salt as the salt parameter, and the field name as the info parameter, perform the HKDF-SHA256 operation to obtain the derived key; Each sensitive field in the target data is encrypted using AES-256-GCM using an independent key composed of a derived key and a random initialization vector, resulting in encrypted data.

[0027] In this embodiment, KMS registers one master key record for each sensitive field type. For example, for the mobile phone number field, a master key MasterKey-P (AES-256, 256 bits) is registered; for the ID card number field, a master key MasterKey-I is registered. Each master key is generated by a cryptographically secure random number generator (32 bytes) and stored in the master key registry after being envelope-encrypted using HSM or Vault. The master key registry only stores master keys categorized by field type, and its number is constant and does not increase with the number of data records. Upon initial runtime, KMS generates a global random salt, record_salt (32 bytes), which is persistently stored in the system configuration table. This record_salt participates in the subsequent HKDF key derivation process as the salt parameter input.

[0028] When a sensitive field in a record needs to be encrypted or decrypted, KMS derives the field key deterministically from the corresponding master key using HKDF-SHA256. Specifically: the master key is retrieved from the master key registry based on the field name; the `info` parameter is constructed as `EncodeUTF8(field_name+"|"+record_id)`; using the master key as input key material, `record_salt` as the salt parameter, and `info` as context information, HKDF-SHA256 is executed, outputting a 32-byte derived key. The same input always produces the same derived key, therefore the field key does not need to be persisted. Different records have different keys for the same field, and different fields within the same record have different keys, maintaining field-level isolation. The plaintext value of the field is encrypted using AES-256-GCM with the derived key and a random initialization vector (12 bytes, 96 bits); the random initialization vector and ciphertext are Base64 encoded, with a version prefix appended, in the format `enc_v1`.<Base64(IV)> .<Base64(ciphertext)> Replace the original field value with the encrypted field value, while retaining the original value for non-sensitive fields.

[0029] In some embodiments, HMAC-SHA256 operations are performed based on the session identifier, field name, user identifier, and server-side cryptographic salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data, including: The session identifier, field name, and user identifier are concatenated using a delimiter to obtain the message string. Using the independent key as the HMAC key, an HMAC-SHA256 operation is performed to obtain the digest seed. Each byte of the multiple bytes in the summary seed is modulo 10 and mapped to a 0-9 numeric character. The resulting string is then concatenated to generate a display tag of the corresponding number of bytes.

[0030] In this embodiment, when a user session is established and sensitive data is queried, the system determines the session identifier, field name, user identifier, and server-side encrypted salt as input parameters. The session identifier, field name, and user identifier are concatenated into a message string using a delimiter. Using the server-side encrypted salt as the HMAC key, an HMAC-SHA256 operation is performed, outputting a 32-byte digest seed. Here, the server-side encrypted salt is a high-entropy random binary key deployed only on the business server, never distributed externally, and inaccessible to the front-end / client. It is the dedicated symmetric key for all HMAC-SHA256 operations of the honeypot module. The first 8 bytes of the seed are taken, and each byte modulo 10 is mapped to a 0-9 numeric character, concatenated to generate an 8-digit display tag. It should be noted that the number of bytes here is only an example; other values ​​are possible and not limited thereto.

[0031] In some embodiments, HMAC-SHA256 operation is performed based on the session identifier, field name, user identifier, and server-side cryptographic salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data, and the method further includes: Each byte of the multiple bytes in the summary seed is modulo 36 and mapped to a predefined character set, and then concatenated to generate the corresponding number of verification tag bodies; The verification tag body is concatenated with a preset fixed suffix, and HMAC-SHA256 operation is performed using the server-side encrypted salt as the HMAC key to obtain multiple bytes of the output digest seed. Each byte is then mapped to a predefined character set by taking the modulo 36 to obtain the corresponding verification code. The verification mark body and the check code are concatenated to obtain the complete verification mark.

[0032] In this embodiment, the first 8 bytes are taken from the aforementioned digest seed. Each byte is mapped modulo 36 to a predefined character set CHARSET ("0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ", 36 characters), and concatenated to generate an 8-digit alphanumeric verification tag body. The tag body is concatenated with the fixed suffix "CHECKSUM", encoded as a UTF-8 byte sequence, and HMAC-SHA256 operation is performed using the server-side encrypted salt as the HMAC key. The first 2 bytes of the output digest are taken, and each byte is mapped modulo 36 to CHARSET, concatenating to generate a 2-digit alphanumeric checksum. The verification tag body (8 bits) and the checksum (2 bits) are concatenated to generate a complete 10-digit verification tag. Similarly, the number of bytes here is only for illustrative purposes and can be other values, which are not limited.

[0033] In some embodiments, after performing HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side cryptographic salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data, the method further includes: Collision detection is performed on the display tag. If the collision probability is greater than the first threshold, HMAC-SHA256 operation is performed using the server-side encrypted salt as the key to add at least one suffix to the display tag until the collision probability is no greater than the first threshold.

[0034] In this embodiment, the display tag is embedded in the desensitized value for extraction after leakage, while the verification tag is stored only on the server for accurate disambiguation and tamper-proofing. When a display tag collision occurs, global uniqueness is ensured through 36^8 ≈ 2.8 trillion combinations of the verification tag. After generating the display tag, the honeypot index table is queried. If different sessions under the same field are found to be using the same display tag, an incremental suffix resolution strategy is used: for the first collision, 1 bit is added to resolve the suffix; for the second collision, 2 bits are added, and so on, ensuring resolution is achieved regardless of the number of collisions. The last two bits of the verification tag are an HMAC checksum, which is verified first during tracing. If the checksum does not match, the tag is determined to have been intentionally tampered with.

[0035] In one optional embodiment, after generating the double-layer tag and querying the honeypot index table, if a conflict is detected between the currently displayed tag and other session records, the collision resolution process is initiated. First, the resolution round variable `suffix_round` is initialized with a value of 1, indicating that a 1-digit numeric suffix needs to be generated for the first conflict. A dedicated hash message string is concatenated, with the concatenation content consisting of the session identifier, field name, user identifier, the fixed conflict identifier string `COLLISION`, and the current resolution round number. Using the server-side encrypted salt as the HMAC operation key, an HMAC-SHA256 hash calculation is performed on the concatenated complete string, outputting a 32-byte collision seed `collision_seed`. The first `suffix_round` bytes are extracted from the generated `collision_seed` byte stream. Each byte's value is converted to a decimal number (0-9) using a modulo 10 operation, and these are concatenated sequentially to obtain a numeric resolution suffix of length equal to the current round number. Extract the first 8 - suffix_round characters of the original 8-bit display marker and concatenate them with the resolved suffix generated in the previous step to reconstruct a new 8-bit display marker, `display_marker`. This ensures the total marker length remains constant and meets the requirements for de-identifying phone numbers and ID cards. The newly generated display marker is then queried again in the honeypot index table for a second check to determine if there are any cross-session duplicate collisions. If no identical display marker is found in the index, the conflict is resolved, and the new marker is stored in the honeypot index. If collisions still exist, the `suffix_round` variable is incremented by 1, duplicate suffixes are added, a longer resolved suffix is ​​recalculated, and the display marker is updated. This process is repeated until no identical display marker exists in the index.

[0036] In some embodiments, based on the desensitization and masking rules corresponding to the field type of the sensitive field, the display tag in the double-layer honeypot tag is embedded into the masking area of ​​the sensitive field to generate a honeypot index table, including: The tag replacement location is determined based on the desensitization and masking rules corresponding to the field type of the sensitive field; Replace the sensitive fields at the tag replacement location in the target data with display tags to generate the corresponding honeypot desensitization value.

[0037] In this embodiment, based on the desensitization and masking rules corresponding to the field type, the display marker is embedded into the masking area of ​​the original data to generate a honeypot desensitized value. For an 11-digit mobile phone number, such as "13812345678", the first 3 digits are retained, and the last 8 digits are replaced with an 8-digit display marker to generate a honeypot desensitized value, such as "13838265078"; for an 18-digit ID card number, such as "110101199001011234", the first 6 digits and the last 4 digits are retained, and the middle 8 digits are replaced with an 8-digit display marker to generate a honeypot desensitized value, such as "110101478123561234".

[0038] In some embodiments, the honeypot index table includes display tags, verification tags, tag bodies, checksums, collision resolution status, collision resolution rounds, field names, user identifiers, session identifiers, original value hashes, and the generation time of each data item.

[0039] In some embodiments, please refer to Figure 2 , Figure 2 This is a schematic diagram of a data security protection system based on honeypot tracing provided in an embodiment of the present invention. The present invention provides a data security protection system 200 based on honeypot tracing, including: a field encryption module 210, a honeypot marking module 220, and a data verification module 230.

[0040] The field encryption module 210 is configured to use an independent key derived from HKDF to encrypt each sensitive field in the target data using AES-256-GCM when performing data entry or query operations on the target data, so as to obtain encrypted data. The honeypot tagging module 220 is configured to perform HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session, generating a unique double-layer honeypot tag for each sensitive field of the encrypted data. Based on the desensitization and masking rules corresponding to the field type of the sensitive field, the display tag in the double-layer honeypot tag is embedded into the masking area of ​​the sensitive field to generate a honeypot index table. The honeypot index table includes multiple specific honeypot desensitization values, and the display tag is bound to the session identifier, field name, and user identifier. The double-layer honeypot tag also includes a verification tag embedded in the server-side honeypot index table. The data verification module 230 is configured to verify the display tag using the verification tag if leaked data related to encrypted data is detected. If the display tag is determined to be unaltered, the module obtains the first honeypot desensitization value in the leaked data and queries the honeypot index table using the first honeypot desensitization value to determine the session identifier and user identifier corresponding to the leaked data.

[0041] In some embodiments, the field encryption module 210 is specifically configured as follows: Retrieve the corresponding master key from the master key registry based on the field name; Using the master key as the input key material, the global random salt as the salt parameter, and the field name as the info parameter, perform the HKDF-SHA256 operation to obtain the derived key; Each sensitive field in the target data is encrypted using AES-256-GCM using an independent key composed of a derived key and a random initialization vector, resulting in encrypted data.

[0042] In some embodiments, the honeypot marking module 220 is specifically configured as follows: The session identifier, field name, and user identifier are concatenated using a delimiter to obtain the message string. The HMAC-SHA256 operation is then performed using the server-side encrypted salt as the HMAC key to obtain the digest seed. Each byte of the multiple bytes in the summary seed is modulo 10 and mapped to a 0-9 numeric character. The resulting string is then concatenated to generate a display tag of the corresponding number of bytes.

[0043] In some embodiments, the honeypot marking module 220 is specifically configured as follows: Each byte of the multiple bytes in the summary seed is modulo 36 and mapped to a predefined character set, and then concatenated to generate the corresponding number of verification tag bodies; The verification tag body is concatenated with a preset fixed suffix, and HMAC-SHA256 operation is performed using the server-side encrypted salt as the HMAC key to obtain multiple bytes of the output digest seed. Each byte is then mapped to a predefined character set by taking the modulo 36 to obtain the corresponding verification code. The verification mark body and the check code are concatenated to obtain the complete verification mark.

[0044] In some embodiments, the honeypot marking module 220 is further configured as follows: Collision detection is performed on the display tag. If the collision probability is greater than the first threshold, HMAC-SHA256 operation is performed using the server-side encrypted salt as the key to add at least one suffix to the display tag until the collision probability is no greater than the first threshold.

[0045] In some embodiments, the honeypot marking module 220 is specifically configured as follows: The tag replacement location is determined based on the desensitization and masking rules corresponding to the field type of the sensitive field; Replace the sensitive fields at the tag replacement location in the target data with display tags to generate the corresponding honeypot desensitization value.

[0046] In some embodiments, the honeypot index table includes display tags, verification tags, tag bodies, checksums, collision resolution status, collision resolution rounds, field names, user identifiers, session identifiers, original value hashes, and the generation time of each data item.

[0047] It should be noted that the data security protection system based on honeypot traceability provided in this application embodiment and the data security protection method based on honeypot traceability provided in this application embodiment are based on the same application concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned data security protection method based on honeypot traceability, and the repeated parts will not be described again.

[0048] In some embodiments, please refer to Figure 3 , Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 300 provided in this embodiment includes a processor 310 and a memory 320; the memory 320 stores a computer program, wherein the computer program, when executed by the processor, implements the aforementioned data security protection method based on honeypot tracing.

[0049] Specifically, processor 310 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. Processor 310 may also include onboard memory for caching purposes. Processor 310 may be a single processing unit or multiple processing units for performing different actions of the method flow according to embodiments of this application.

[0050] The memory 320 may be any medium capable of containing, storing, transmitting, propagating, or transmitting instructions. For example, the memory 320 may include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, apparatuses, or propagation media. Specific examples of the memory 320 include: magnetic storage devices such as magnetic tape or hard disk drives (HDDs); optical storage devices such as optical discs (CD-ROMs); and may also be random access memory (RAM) or flash memory; and / or wired / wireless communication links.

[0051] This application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, this program implements the aforementioned data security protection method based on honeypot tracing. This computer-readable medium may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into that device / apparatus / system. The aforementioned computer-readable medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0052] According to embodiments of this application, a computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wired, optical fiber, radio frequency signals, etc., or any suitable combination thereof.

[0053] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. All such combinations and / or combinations fall within the scope of this application. Therefore, the scope of this application should not be limited to the above embodiments, but should be defined not only by the appended claims, but also by the equivalents of the appended claims. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the protection scope of this invention.

Claims

1. A data security protection method based on honeypot tracing, characterized in that, include: When performing data entry or query operations on the target data, each sensitive field in the target data is encrypted using an independent key derived from HKDF to obtain encrypted data; Based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session, an HMAC-SHA256 operation is performed to generate a unique double-layer honeypot tag for each sensitive field of the encrypted data. Then, based on the desensitization and masking rules corresponding to the field type of the sensitive field, a display tag from the double-layer honeypot tag is embedded into the masking area of ​​the sensitive field, generating a honeypot index table. The honeypot index table includes multiple specific honeypot desensitization values. The display tag is bound to the session identifier, the field name, and the user identifier. The double-layer honeypot tag also includes a verification tag embedded in the server-side honeypot index table. If leaked data related to the encrypted data is detected, the display tag is verified using the verification tag. If the display tag is determined to be unaltered, the first honeypot desensitization value in the leaked data is obtained, and the honeypot index table is queried using the first honeypot desensitization value to determine the session identifier and user identifier corresponding to the leaked data.

2. The data security protection method based on honeypot tracing as described in claim 1, characterized in that, The method involves using an independent key derived from HKDF to encrypt each sensitive field in the target data using AES-256-GCM, resulting in encrypted data, including: Retrieve the corresponding master key from the master key registry based on the field name; Using the master key as the input key material, the global random salt as the salt parameter, and the field name as the info parameter, perform HKDF-SHA256 operation to obtain the derived key; Each sensitive field in the target data is encrypted using AES-256-GCM using an independent key composed of the derived key and a random initialization vector to obtain encrypted data.

3. The data security protection method based on honeypot tracing as described in claim 1, characterized in that, The process involves performing HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data, including: The session identifier, the field name, and the user identifier are concatenated using a delimiter to obtain a message string. The HMAC-SHA256 operation is then performed using the server-side encrypted salt as the HMAC key to obtain the digest seed. Each byte of the multiple bytes in the summary seed is modulo 10 and mapped to a 0-9 numeric character. The resulting concatenation generates a display marker of the corresponding number of bytes.

4. The data security protection method based on honeypot tracing as described in claim 3, characterized in that, The step of performing HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data also includes: Each byte of the multiple bytes in the summary seed is modulo 36 and mapped to a predefined character set, and then concatenated to generate a verification tag body of the corresponding number of bytes; The verification tag body is concatenated with a preset fixed suffix, and HMAC-SHA256 operation is performed using the server-side encrypted salt as the HMAC key to obtain multiple bytes of the output digest seed. Each byte is then mapped to the predefined character set by taking the modulo 36 to obtain the corresponding verification code. The verification mark body and the check code are concatenated to obtain the complete verification mark.

5. The data security protection method based on honeypot tracing as described in claim 1, characterized in that, After performing HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side cryptographic salt corresponding to the current session to generate a unique two-layer honeypot tag for each sensitive field of the encrypted data, the process further includes: Collision detection is performed on the display tag. If the collision probability is greater than the first threshold, HMAC-SHA256 operation is performed using the server-side encrypted salt as the key to add at least one suffix to the display tag until the collision probability is no greater than the first threshold.

6. The data security protection method based on honeypot tracing as described in claim 1, characterized in that, The desensitization and masking rules based on the field type of the sensitive field embed the display tags in the double-layer honeypot tag into the masking area of ​​the sensitive field, generating a honeypot index table, including: The marker replacement position is determined based on the desensitization and masking rules corresponding to the field type of the sensitive field; The sensitive fields at the designated replacement locations in the target data are replaced with display tags to generate corresponding honeypot desensitization values.

7. The data security protection method based on honeypot tracing as described in claim 1, characterized in that, The honeypot index table includes display tags, verification tags, tag body, checksum, collision resolution status, collision resolution round, field name, user identifier, session identifier, original value hash, and generation time of each data.

8. A data security protection system based on honeypot traceability, characterized in that, It includes: a field encryption module, a honeypot marking module, and a data verification module; among which, The field encryption module is configured to use an independent key derived from HKDF to encrypt each sensitive field in the target data using AES-256-GCM when performing data entry or query operations on the target data, thereby obtaining encrypted data. The honeypot tagging module is configured to perform HMAC-SHA256 operations based on the session identifier, field name, user identifier, and server-side encrypted salt corresponding to the current session to generate a unique double-layer honeypot tag for each sensitive field of the encrypted data. Based on the desensitization and masking rules corresponding to the field type of the sensitive field, the module embeds the display tag from the double-layer honeypot tag into the masking area of ​​the sensitive field, generating a honeypot index table. The honeypot index table includes multiple specific honeypot desensitization values. The display tag is bound to the session identifier, the field name, and the user identifier. The double-layer honeypot tag also includes a verification tag embedded in the server-side honeypot index table. The data verification module is configured to, if leaked data related to the encrypted data is detected, verify the display tag using the verification tag, and if it is determined that the display tag has not been tampered with, obtain the first honeypot desensitization value in the leaked data, and query the honeypot index table through the first honeypot desensitization value to determine the session identifier and user identifier corresponding to the leaked data.

9. An electronic device, characterized in that, It includes a processor and a memory; the memory stores a computer program, wherein the computer program, when executed by the processor, implements the data security protection method based on honeypot tracing as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, It stores a computer program, wherein when the computer program is executed by a processor, it implements the data security protection method based on honeypot tracing as described in any one of claims 1 to 7.

Images