High-performance unique identifier generation method and system based on privacy protection

Abstract

The invention provides a high-performance unique identifier generation method and system based on privacy protection, and belongs to the technical field of privacy protection identifier generation, and the method comprises the following steps: a user defines and represents different SS-UID classifications, and generates category classification bytes; performing sequence uncovering encryption on information provided by a user to generate encrypted data; verifying the generated encrypted data to generate verification bytes; generating a random encryption byte which is a random encryption field based on a timestamp and is used for ensuring the uniqueness of the unique identifier after verification; a unique ID is defined, and the name of the unique ID is SS-UID; comprising S1, S2, S3 and S4, S1 is a category classification byte, S2 is encrypted data, S3 is a verification byte, and S4 is a random encryption byte.

Description

Technical Field

[0001] This invention belongs to the field of privacy-preserving identifier generation technology, and in particular relates to a high-performance unique identifier generation method and system based on privacy protection. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] In scenarios involving the protection of sensitive information in databases, a secure and efficient method is sometimes needed to uniquely identify the information—a unique ID. This unique ID is used to quickly locate a piece of information without compromising privacy. For example, in medical information protection scenarios, four pieces of patient information need to be protected: name, ID card number, mobile phone number, and home address. While the ID card number can uniquely identify a patient and related information, directly using the ID card number as the unique ID would leak privacy information; therefore, other methods must be used to generate this unique ID.

[0004] The current industry standard for generating unique IDs is UUID, short for Universally Unique Identifier. UUID is a universally unique identifier, and it has several different implementations, each with significantly different algorithms. A summary of current UUID algorithms is shown in Table 1.

[0005] Table 1

[0006] Among the UUID algorithms mentioned above, the fourth algorithm is currently recommended internationally because it does not leak MAC address information and has an ordered nature. However, in database privacy protection scenarios, the fourth algorithm using UUIDs still has the following shortcomings: First, it leaks time information, making it insecure. Second, information is difficult to trace, as timestamp-based UUIDs cannot be linked to patient information. Third, it is unsuitable for privacy protection scenarios, because in such scenarios, this unique ID is also information to be protected, while UUIDs are designed for insecure environments. Fourth, it has poor performance, failing to quickly locate the ID. Fifth, its functionality is simple and unsuitable for scenarios requiring verification and deduplication.

[0007] Therefore, UUIDs simply generate different IDs, and in privacy protection scenarios, traditional UUIDs cannot meet the security requirements for privacy protection. Summary of the Invention

[0008] To overcome the shortcomings of the prior art, this invention provides a high-performance unique identifier generation method and system based on privacy protection, which is more secure and efficient, can quickly locate a unique ID without disclosing any information, and has verification capabilities.

[0009] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions: Firstly, a high-performance unique identifier generation method based on privacy protection is disclosed, including: Defined by the user, it represents different SS-UID categories and generates category classification bytes; The information provided by the user is decrypted and encrypted to generate encrypted data; Verify the generated encrypted data and generate verification bytes; Generate random encrypted bytes, which are timestamp-based random encrypted fields used to ensure the uniqueness of the verified unique identifier; Define a unique ID named SS-UID; including S1, S2, S3, and S4, where S1 is the category byte, S2 is the encrypted data, S3 is the verification byte, and S4 is the random encrypted byte.

[0010] As a further technical solution, the information provided by the user is decrypted and encrypted, including: After encrypting plaintext that can be compared in size into ciphertext, the ciphertext still implicitly contains the size information of the plaintext. By calculating the size relationship between the two ciphertexts, we can find out their relative sizes.

[0011] As a further technical solution, when generating random encrypted bytes, the timestamp is encrypted using SM4. SM4 is a symmetric encryption, and the encrypted ciphertext is 16 bytes long, all of which are used as the content of the S4 field.

[0012] As a further technical solution, when generating random encrypted bytes, the timestamp is encrypted using SM3. SM3 is a hash encryption, and the encrypted hash value is 32 bytes. The last 16 bytes are taken as the content of the S4 field.

[0013] As a further technical solution, a query step is also included, specifically: designing an indexable structure, indexing the S2 field of all SS-UIDs, and then indexing the data in the S2 field according to its S1 category.

[0014] As a further technical solution, a high-performance unique identifier generation method based on privacy protection is applied to medical information systems, including: The patient's name, ID number, mobile phone number, and home address are extracted from the system and encrypted separately. The encrypted sensitive information is then made into a separate microservice or sub-module, and the entire system can use it through SS-UID as an interface. As a further technical solution, the patient's registration number is used to generate an SS-UID. When a patient registers for the first time, the patient's information, including name, ID number, mobile phone number, home address, and registration number, is transmitted to the aforementioned microservice. The microservice generates an SS-UID based on the registration number, encrypts and saves the patient's sensitive information, and then returns the newly generated SS-UID to the registration system. Afterwards, any application system that wants to obtain this patient's information only needs to send the patient's medical number to the microservice. The microservice will find the corresponding SS-UID based on the medical number and return it to the application system. This SS-UID identifies the patient's information. The application system only needs to use this SS-UID to uniquely locate the patient without involving the patient's sensitive privacy information.

[0015] Secondly, a high-performance unique identifier generation system based on privacy protection is disclosed, including: The category classification byte generation module is configured to be user-defined, representing different SS-UID categories, and generating category classification bytes. The encrypted data generation module is configured to: decrypt and encrypt user-provided information to generate encrypted data; The verification byte generation module is configured to: verify the generated encrypted data and generate verification bytes; The random encrypted byte generation module is configured to generate random encrypted bytes, which are timestamp-based random encrypted fields used to ensure the uniqueness of the verified unique identifier; The unique identifier generation module is configured to: define a unique ID named SS-UID; including S1, S2, S3, and S4, where S1 is the category classification byte, S2 is the encrypted data, S3 is the verification byte, and S4 is the random encrypted byte.

[0016] The above one or more technical solutions have the following beneficial effects: In database privacy protection scenarios, the technical solution of this invention can generate a unique ID without disclosing information. It can quickly locate, efficiently index, and support verification.

[0017] The SS-UID of this invention is completely different from the traditional UUID. UUIDs cannot balance security and performance, information is difficult to trace, and they lack data verification capabilities. The unique identifier generated by this method is more secure. SS-UIDs do not reveal any information, including time information that is easily leaked by traditional UUIDs. SS-UIDs possess uniqueness and extremely high security, making them suitable for privacy-protecting scenarios. The unique identifiers generated by this method have higher performance. SS-UIDs guarantee that their data can be sorted, and the sorting field is based on ciphertext, making it both secure and efficient. Furthermore, a new index structure has been designed for SS-UIDs, greatly improving performance.

[0018] The unique identifier generated by this method incorporates data validation. The SS-UID adds data validation functionality, which can identify input errors and locate duplicate SS-UIDs. The validation fields do not reveal any information.

[0019] The unique identifier generated by this method can be flexibly configured as needed. SS-UID allows setting a category field S1, configuring whether to run duplicate values, configuring whether to enable verification, and configuring the encryption algorithm for the random field, making it suitable for a wide range of real-world scenarios.

[0020] This method generates unique identifiers that can be bidirectionally associated. Traditional UUIDs are unidirectional; their main design purpose is to generate a unique ID for certain data, but this ID has almost no connection with the data. Therefore, data can only be located through the UUID, not the other way around. SS-UIDs, on the other hand, associate the SS-UID with the data while ensuring security, allowing the corresponding SS-UID to be retrieved from the data.

[0021] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0023] Figure 1 This is a schematic diagram illustrating the structure of the SS-UID in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the entire SS-UID generation process in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the SS-UID query process according to an embodiment of the present invention. Figure 4 This is an overall index structure diagram of an embodiment of the present invention; Figure 5 This is an index structure diagram for a certain category in an embodiment of the present invention. Detailed Implementation

[0024] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0025] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0026] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0027] Example 1 This embodiment discloses a high-performance unique identifier generation method based on privacy protection, including: Defined by the user, it represents different SS-UID categories and generates category classification bytes; The information provided by the user is decrypted and encrypted to generate encrypted data; Verify the generated encrypted data and generate verification bytes; Generate random encrypted bytes, which are timestamp-based random encrypted fields used to ensure the uniqueness of the verified unique identifier; Define a unique ID named SS-UID; including S1, S2, S3, and S4, where S1 is the category byte, S2 is the encrypted data, S3 is the verification byte, and S4 is the random encrypted byte.

[0028] In this implementation example, a new unique ID is designed, named SS-UID (Secure, Sortable, Universal ID), and its structure is as follows: Figure 1 As shown.

[0029] The descriptions of each component are shown in Table 2.

[0030] Table 2

[0031] The entire SS-UID contains 37 bytes. Traditional UUIDs are generated based on timestamps, random numbers, or MAC addresses, while SS-UIDs are generated based on arbitrary values ​​provided by the user (preferably sortable values). The S1 part is 1 byte, the S2 part is 16 bytes, the S3 part is 4 bytes, and the S4 part is 16 bytes. The generation and usage of each part are described below.

[0032] S1 Generation: Its value ranges from 0 to 255 and is defined by the user to represent different SS-UID categories. For example, 1 indicates that the SS-UID is generated using the patient's medical record number, and 2 indicates that the SS-UID is generated using the national ID card number. The default value is 0.

[0033] S2 generation: User-provided information, such as the patient's registration number, is deordered and encrypted (ORE). The deordered encryption works by encrypting plaintext that can be compared in size into ciphertext. The ciphertext still implicitly contains the size information of the plaintext. The size relationship between the two ciphertexts can be determined by calculating the size of the two ciphertexts using the ORE_CMP function, without the need for decryption. S2 is the deordered encrypted ciphertext data, occupying 16 bytes.

[0034] S3 Generation: S3 is used for verification. For example, a user provides a medical appointment number to generate an SS-UID. However, the same patient may have two different medical appointment numbers. In this case, the S3 field is needed for verification to identify this situation. For instance, when generating this SS-UID, in addition to providing the medical appointment number, the patient's name is also provided for verification. The patient's name will then be used to generate the S3. The specific generation algorithm is as follows: hash the patient's name to obtain a hash value, and take the last 4 bytes of the hash value as S3. This field is optional, and the default value is all 0s.

[0035] S4 Generation: S4 is a timestamp-based random encrypted field. This random field ensures the uniqueness of the SS-UID and guarantees that SS-UID values ​​will not conflict under high concurrency. It is generated based on the timestamp of the moment the SS-UID is generated, and there are two generation methods: 1. Use SM4 to encrypt the timestamp. SM4 is a symmetric encryption method. The encrypted ciphertext is 16 bytes long, and all of it is used as the content of the S4 field. 2. Use SM3 to encrypt the timestamp. SM3 is a hash encryption method. The encrypted hash value is 32 bytes. Take the last 16 bytes as the content of the S4 field.

[0036] The two methods described above are for different scenarios. The SM4-encrypted S4 can be decrypted using the encryption key to obtain the time information that generated the SS-UID. This method is suitable for scenarios where time information needs to be retained. The SM3-encrypted S4 cannot be decrypted and the time information cannot be obtained. This method is suitable for scenarios where time information is not required.

[0037] Regarding the SS-UID configuration options, the specific configurable options for SS-UID are shown in Table 3: Table 3

[0038] S4.encrypt is used to determine which encryption algorithm can be used for the S4 field; it can be either SM3 or SM4. SM3 encryption results in unrecoverable plaintext, while SM4 encryption allows for plaintext recovery, depending on the specific scenario and security requirements.

[0039] SS-UID generation process: When generating an SS-UID, three pieces of information are required: 1. Classification information for S1 - R1, where R1 can be 0-255 with a customizable meaning. For example, 1 represents an ID card number, 2 represents a mobile phone number, and 3 represents a medical appointment number. R1 is not required when S1.enable is set to false; 2. Identification information for generating S2 - R2. If R1 is 2 (mobile phone number), then R2 is 13838457568, a mobile phone number. This information is mandatory; 3. Verification information for generating S3 - R3. R3 is not required when S3.enable is set to false. If verification is enabled, verification information must be entered here, such as using a name. Enter "Zhang San" here. The person with the mobile phone number 13838457568 must be called Zhang San; otherwise, verification will fail.

[0040] The steps for generating an SS-UID are as follows: 1. Set all fields S1, S2, S3, and S4 to 0.

[0041] 2. If S1.enable is true, then the input R1 is stored in S1; otherwise, S1 remains 0.

[0042] 3. Encrypt the input R2 using ORE to obtain the ciphertext RS2. The encryption key is obtained from the cipher machine.

[0043] 4. If S2.unique is true, it means that duplicate S2 values ​​are not allowed. In this case, RS2 is retrieved from the existing SS-UIDs. If RS2 already exists, an error is reported and the process exits. If RS2 does not exist, or S2.unique is false, then RS2 is stored in S2.

[0044] 5. If S3.enable is true, it means that verification is enabled. The input R3 is hashed and the last 4 bytes are stored in S3.

[0045] 6. Calculate S4. Based on the settings of S4.encrypt, encrypt the obtained timestamp into SM4 or SM3 and store the ciphertext in S4.

[0046] 7. Combine the S1, S2, S3, and S4 obtained above to form a complete SS-UID.

[0047] The entire SS-UID generation process flowchart is as follows: Figure 2 As shown.

[0048] SS-UID lookup process: When generating an SS-UID, three pieces of information need to be entered: 1. Classification information - T1 (T1 does not need to be entered when S1.enable is set to false); 2. Identification information - T2, which is required; 3. Verification information - T3 (T3 does not need to be entered when S3.enable is set to false).

[0049] The steps to find the SS-UID are as follows: (1) If S1.enable is false, it means that classification is not enabled, so set T1 to 0. Otherwise, T1 remains unchanged.

[0050] (2) Encrypt the input T2 with ORE to obtain the ciphertext TS2, and obtain the key from the cipher machine.

[0051] (3) Perform SS-UID lookup with the search conditions being S1=T1 and S2=TS2. The query will be based on the index to improve efficiency.

[0052] (4) If the above search does not find the result, return an empty value and the search ends. If the result is found, proceed to step 5. (5) Determine if S3.enable is false. If it is false, it means no verification is performed. Then return the found SS-UID and the query ends. If it is true, proceed to step 6.

[0053] (6) Perform hash calculation on the input verification information T3, take the last 4 bytes as TS3 and compare it with S3 in the found SS-UID. If the comparison result is consistent, the verification is successful, return this SS-UID, and the query ends. If the comparison result is inconsistent, proceed to step 7.

[0054] (7) Check S2.unique. If it is true, it means that duplicate S2s are not allowed, so return null and end the query. If it is false, it means that duplicate S2s are allowed, so go to step 3 and continue the search.

[0055] The SS-UID is used in the specific process based on the above lookup steps. Traditional UUIDs can only look up information based on the UUID, not the other way around. This step explains how to calculate the SS-UID based on the information, ensuring data security and performance throughout the entire process.

[0056] The SS-UID lookup process is as follows: Figure 3 As shown.

[0057] The index structure of SS-UID: Of the four fields S1, S2, S3, and S4 of SS-UID, S2 is the most important and mandatory field, S1 is an optional category field, S3 is an optional validation field, and S4 is a random field to prevent data collisions. To enable fast retrieval and location of SS-UIDs, this invention designs an indexable structure for SS-UIDs, the overall index structure of which is as follows: Figure 4 As shown.

[0058] superior Figure 4 In the index structure, the S2 field of all SS-UIDs needs to be indexed. However, unlike traditional indexes, this index categorizes the S2 field data according to its S1 category before indexing. The S1 category field has a value range of 0 to 255, so this index supports a maximum of 256 categories. This design is because S2 values ​​from different categories may not be comparable. For example, S2 values ​​in category 1 might be generated from encrypted ID card numbers, while S2 values ​​in category 2 might be generated from encrypted mobile phone numbers. It's impossible to compare an ID card number with a mobile phone number, so categories are used to distinguish them.

[0059] For a specific category of index, its structure is similar to that of a B-tree index, but also quite different. Its structure is as follows: Figure 5 As shown. superior Figure 5 In the diagram, blue represents index pointers, and orange represents data. The main difference between the index architecture shown above and traditional indexes is that: The index data is different: the data in this index is ORE encrypted data (i.e., the data in the S2 field). The size comparison of the data in this index uses a special comparison function of the unordered encrypted ORE to compare the size of the encrypted data, and the index is built and used based on this.

[0060] Allowing Duplicate Values: Traditional B-tree indexes or similar indexes do not allow duplicate values. The index of this invention is optimized for SS-UID indexing scenarios, allowing duplicate values. SS-UIDs themselves do not have duplicate values ​​because they are composed of four fields: S1, S2, S3, and S4. The S4 field is a random field, ensuring that each SS-UID is unique. However, the S2 field is used for indexing, and different SS-UIDs can have the same S2 field (when the configuration option S2.unique is false, identical S2 fields are allowed). Traditional indexes cannot be used when duplicate values ​​are present. The index of this invention stores the S2 data in leaf nodes, with each leaf node storing multiple SS-UIDs. Each indexed SS-UID is split into two parts: one part is the S2 field, and the other part is the S1+S3+S4 field (this part is called data). Taking the leftmost leaf node in the diagram above as an example, this node stores 5 SS-UIDs: S2-1+data1-1 is the first SS-UID, S2-1+data1-2 is the second SS-UID, which shares the same S2 field as the first SS-UID. S2-2+data2-1 is the third SS-UID, S2-3+data3-1 is the fourth SS-UID, and S2-3+data3-2 is the fifth SS-UID, which shares the same S2 field as the fourth SS-UID.

[0061] Only leaf nodes store data: In this index, only leaf nodes store SS-UID data, and the values ​​in non-leaf nodes are used to maintain the index structure.

[0062] The remaining properties of this index follow the characteristics of a traditional B-Tree structure.

[0063] A specific example: For example, in a medical information system, to protect four fields—patient's name, ID number, mobile phone number, and home address—to minimize system modifications, these four fields are extracted from the system, encrypted separately, and the encrypted sensitive information is made into a microservice or a separate submodule, using SS-UID as the interface for the entire system. These four sensitive fields no longer appear in the original system, and inter-system interactions rely on SS-UID to transmit patient information. Adversaries cannot deduce any sensitive information from the SS-UID, including time information (this prevents snooping on the registration system and leaking patient information based on registration time).

[0064] In the simplest scenario of this system, a patient's appointment number can be used to generate an SS-UID. For example, when a patient registers for the first time, their information (name, ID number, mobile phone number, home address) and appointment number are sent to the aforementioned microservice. The microservice generates an SS-UID based on the appointment number, encrypts and saves the patient's sensitive information, and then returns the newly generated SS-UID to the registration system. Afterward, any application system that wants to obtain this patient's information only needs to send the appointment number to the microservice. The microservice finds the corresponding SS-UID based on the appointment number and returns it to the application system. This SS-UID identifies the patient's information, and the application system can uniquely locate the patient based on this SS-UID without involving the patient's sensitive privacy information.

[0065] Ideally, all applications using SS-UID microservices should use the same S2 (e.g., all using patient registration numbers to generate S2). However, in real-world scenarios, different hospital systems are designed and developed by different vendors, using different primary IDs. Requiring each application system to be modified (e.g., to use patient registration numbers as their primary ID) is impractical, involving a huge workload and difficult to implement. Therefore, a category field S1 was added to the SS-UID design to address this issue. If application system A uses patient registration numbers as its primary ID, and application system B uses ID card numbers, then application systems A and B can use different S1 categories. This allows for the protection of sensitive information with less modification work. However, enabling the S1 category field also has negative effects. Duplicate patients in application systems A and B cannot be distinguished because their primary IDs are different, resulting in different SS-UIDs. However, this adheres to the original design of application systems A and B, so it is acceptable and can function normally.

[0066] The S3 field is used for validation in several scenarios: 1. It prevents incorrect input when querying SS-UIDs; 2. It helps to accurately locate duplicate SS-UIDs with the same S2 field. For example, an SS-UID might be generated using a patient's appointment number (005566) and the patient's name (Zhang San). However, if a user incorrectly enters the appointment number (006655) and the patient's name (Zhang San) when querying the SS-UID using a microservice, the microservice will retrieve the SS-UID of patient number 006655. Because validation is enabled, it will further validate the S3 field of this SS-UID using a hash generated from the patient's name. If the validation fails, the microservice will report that the person was not found.

[0067] In some cases, duplicate S2 fields of SS-UIDs are allowed. For example, a newborn may only have a medical record number and no name. Later, the name information may be updated after the name is added, but the medical record number remains unchanged. In this case, there will be two SS-UIDs in the microservice, with the same S2 field but different S3 verification fields (and their S4 random fields are also different). In this situation, the patient's SS-UID can be accurately found through the S3 verification field.

[0068] The S4 random field of SS-UID has three uses: 1. Preventing SS-UID collisions: While allowing duplicate S2 fields, if multiple application systems concurrently request to generate SS-UIDs, the S4 field will generate random data based on the timestamp of the request, avoiding collisions. 2. Enhancing security: The addition of the S4 random field makes the entire SS-UID more difficult to crack and reverse engineer, ensuring overall security. 3. Retaining time information: The S4 field can be configured with either the SM3 or SM4 algorithm. The SM3 algorithm is a hash algorithm and cannot be used to deduce the time, while the SM4 algorithm is a symmetric algorithm and can be decrypted into timestamp information using a key in a cryptographic machine. In scenarios where users need to retain time information, configuring the S4 field with the SM4 algorithm can securely retain the time information used to generate the SS-UID.

[0069] Example 2 The purpose of this embodiment is to provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the above-described method.

[0070] Example 3 The purpose of this embodiment is to provide a computer-readable storage medium.

[0071] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the above method.

[0072] Example 4 The purpose of this embodiment is to provide a high-performance unique identifier generation system based on privacy protection, including: The category classification byte generation module is configured to be user-defined, representing different SS-UID categories, and generating category classification bytes. The encrypted data generation module is configured to: decrypt and encrypt user-provided information to generate encrypted data; The verification byte generation module is configured to: verify the generated encrypted data and generate verification bytes; The random encrypted byte generation module is configured to generate random encrypted bytes, which are timestamp-based random encrypted fields used to ensure the uniqueness of the verified unique identifier; The unique identifier generation module is configured to: define a unique ID named SS-UID; including S1, S2, S3, and S4, where S1 is the category classification byte, S2 is the encrypted data, S3 is the verification byte, and S4 is the random encrypted byte.

[0073] Example 5 The purpose of this embodiment is to provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods and functions involved in any of the above embodiments. The steps and methods involved in the apparatus of the above embodiments correspond to those in Embodiment 1. For specific implementation details, please refer to the relevant description section of Embodiment 1. The term "computer-readable storage medium" should be understood as a single medium or multiple media including one or more instruction sets; it should also be understood as including any medium capable of storing, encoding, or carrying an instruction set for execution by a processor and enabling the processor to perform any of the methods in this invention.

[0074] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0075] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A privacy protection based high performance unique identification generation method, characterized in that, Comprise: Defined by the user, representing different SS-UID classification, generating category classification bytes; The information provided by the user is encrypted, and encrypted data is generated; The generated encrypted data is checked, and check bytes are generated; Generate random encryption bytes, a random encryption field based on timestamp, used to ensure the uniqueness of the unique identifier after verification; Define a unique ID, named SS-UID; including S1, S2, S3, S4, S1 is the category classification byte, S2 is the encrypted data, S3 is the check byte, and S4 is the random encryption byte.

2. The high-performance unique identification generation method based on privacy protection according to claim 1, characterized in that, When generating random encryption bytes, use SM4 to encrypt the timestamp, SM4 is symmetric encryption, and the length of the encrypted ciphertext is 16 bytes, all of which are the contents of the S4 field.

3. The high-performance unique identification generation method based on privacy protection according to claim 1, characterized in that, When generating random encryption bytes, use SM3 to encrypt the timestamp, SM3 is a hash encryption, and the length of the encrypted hash value is 32 bytes, and the last 16 bytes are the contents of the S4 field.

4. The high-performance unique identification generation method based on privacy protection of claim 1, characterized in that, It also includes a query step, specifically including: designing an indexable structure, indexing all SS-UID S2 fields, and indexing the data in the S2 field after classifying it according to its S1 category.

5. The high-performance unique identification generation method based on privacy protection according to claim 1, characterized in that, The high-performance unique identifier generation method based on privacy protection is applied to a medical information system, comprising: Separate the patient's name, ID number, mobile phone number, and home address from the system, separately encrypt and protect them, and independently encrypt the sensitive information as a microservice or a separate sub-module, and use SS-UID as an interface for the entire system.

6. The high-performance unique identification generation method based on privacy protection according to claim 1, characterized in that, Use the patient's registration number to generate SS-UID. When the patient first registers, the patient's information including name, ID number, mobile phone number, home address and registration number is transmitted to the microservice, and the microservice generates an SS-UID based on the registration number. Then save the encrypted sensitive information of this patient, and then return the newly generated SS-UID to the registration system; After that, any application system wants to obtain the information of this patient, it only needs to transmit the registration number to the microservice, and the microservice finds the corresponding SS-UID based on the registration number and returns it to the application system. This SS-UID identifies the patient's information, and the application system only needs to be based on this SS-UID to uniquely identify the patient without involving the patient's private sensitive information.

7. A high performance unique identification generation system based on privacy protection, characterized in that, Comprise: Category classification byte generation module, configured to: defined by the user, representing different SS-UID classification, generating category classification bytes; The encrypted data generation module is configured to: encrypt the information provided by the user in sequence to generate encrypted data; The check byte generation module is configured to: check the generated encrypted data to generate check bytes; The random encryption byte generation module is configured to: generate random encryption bytes, a random encryption field based on timestamp, used to ensure the uniqueness of the unique identifier after verification; The unique identifier generation module is configured to: define a unique ID, named SS-UID; including S1, S2, S3, S4, S1 is the category classification byte, S2 is the encrypted data, S3 is the check byte, and S4 is the random encryption byte.

8. A computer program product comprising a computer program, characterized in that, The computer program, which is executed by a processor, implements the method of any one of claims 1 to 6.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor, when executing the program, implements the steps of the method of any one of the preceding claims 1 to 6.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program, when executed by a processor, implements the steps of the method of any one of the preceding claims 1 to 6.

Images