Mobile phone number management method and device, equipment and storage medium

Abstract

The invention provides a mobile phone number management method and device, equipment and a storage medium, and the method is used for carrying out encryption storage on a mobile phone number, and comprises the steps: obtaining an encryption key of a current to-be-encrypted mobile phone number from a key library, encrypting the mobile phone number through the encryption key, and generating mobile phone number ciphertext data; and constructing an index for the mobile phone number ciphertext data, and synchronously storing the mobile phone number ciphertext data and the index. Compared with the traditional problem that the encrypted mobile phone number ciphertext cannot be directly subjected to fuzzy matching, the technical scheme of the invention realizes the index construction of the mobile phone number ciphertext, further realizes the efficient fuzzy matching of the mobile phone number ciphertext under the condition of not exposing the original mobile phone number, and improves the availability of the system.

Description

Technical Field

[0001] This disclosure relates to the field of data storage technology, and in particular to a method, apparatus, device and storage medium for managing mobile phone numbers. Background Technology

[0002] In existing user data management scenarios, mobile phone numbers, as core user identification information, are widely used in business processes such as registration and login, message notifications, and marketing recommendations. To meet regulatory requirements and protect user privacy, mobile phone numbers are typically stored in encrypted form. In current data security systems, personal information such as mobile phone numbers is usually stored using AES encryption to ensure that the original text cannot be reverse-analyzed in the event of a database leak. However, business applications often require querying, matching, deduplication, or fuzzy searching based on mobile phone numbers (e.g., locating users based on the last four digits), but traditional AES-encrypted ciphertext of mobile phone numbers cannot be directly used for fuzzy matching. Therefore, how to achieve efficient fuzzy matching of encrypted mobile phone numbers without exposing the original mobile phone number has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0003] In view of this, this disclosure proposes a method, apparatus, device and storage medium for managing mobile phone numbers. The method constructs an index on the ciphertext of AES-encrypted mobile phone numbers, thereby achieving efficient fuzzy query in the ciphertext state of mobile phone numbers and improving the availability of the system.

[0004] According to one aspect of this disclosure, a method for managing mobile phone numbers is provided for encrypting and storing mobile phone numbers, including: Obtain the encryption key for the current mobile phone number to be encrypted from the key store, and use the encryption key to encrypt the mobile phone number to generate encrypted mobile phone number data; An index is built on the encrypted mobile phone number data, and the encrypted mobile phone number data and the index are stored synchronously.

[0005] In one possible implementation, the encryption key is stored in the key store in the following manner: Obtain the randomly generated initial dynamic key and the currently stored encryption key; The initial dynamic key and the encryption key are combined to generate a dynamic key; The dynamic key is encrypted using an asymmetric encryption algorithm to generate a final key, which is then stored in the key repository as storage data.

[0006] In one possible implementation, when obtaining the encryption key for the mobile number to be encrypted from a key store and encrypting the mobile number using the encryption key, the method further includes: Obtain the permission level data of the mobile phone number, select different encryption keys for different permission levels, and use different encryption keys to encrypt the mobile phone number under different permission levels to generate encrypted mobile phone number data under different permission levels.

[0007] In one possible implementation, when encrypting the mobile number using the encryption key, different masking rules are employed for encryption processing.

[0008] In one possible implementation, the indexing of the encrypted mobile phone number data includes: The mobile phone number is segmented to obtain multiple data segments of the mobile phone number; A hash operation is performed on each of the data slices to generate a hash value for each data slice, and the hash value is used as an index for the data slice.

[0009] In one possible implementation, performing a hash operation on each of the data slices includes: Obtain the randomly generated perturbation factor; The perturbation factor is combined with the data slice to generate index features; The hash value is obtained by performing a hash operation on the index feature.

[0010] According to a second aspect of this disclosure, a mobile phone number management device is provided for encrypted storage of mobile phone numbers, including: Mobile phone number encryption module: Obtains the encryption key for the mobile phone number to be encrypted from the key library, and uses the encryption key to encrypt the mobile phone number to generate encrypted mobile phone number data; Index building module: Builds an index on the encrypted mobile phone number data, and stores the encrypted mobile phone number data and the index synchronously.

[0011] According to a third aspect of this disclosure, a mobile phone number management device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the above-described method.

[0012] According to a fourth aspect of this disclosure, a non-volatile computer-readable storage medium is provided that stores computer program instructions thereon, wherein the computer program instructions, when executed by a processor, implement the above-described method.

[0013] This disclosure provides a method, apparatus, device, and storage medium for mobile phone number management. The method includes: obtaining an encryption key for a mobile phone number to be encrypted from a key library, encrypting the mobile phone number using the encryption key to generate encrypted mobile phone number data; constructing an index for the encrypted mobile phone number data, and synchronously storing the encrypted mobile phone number data and the index. This method achieves efficient fuzzy matching in the encrypted state of the mobile phone number by constructing an index on the AES-encrypted encrypted mobile phone number, thereby improving the availability of the system.

[0014] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0015] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0016] Figure 1 A flowchart illustrating a mobile phone number management method according to an embodiment of the present disclosure is shown; Figure 2 A flowchart illustrating dynamic key generation according to an embodiment of the present disclosure is shown; Figure 3 An example diagram of dynamic key generation according to an embodiment of the present disclosure is shown; Figure 4 This diagram illustrates a mobile phone number encryption / decryption flowchart according to an embodiment of the present disclosure; Figure 5 This diagram illustrates a mobile phone number preprocessing flowchart according to an embodiment of the present disclosure; Figure 6 This diagram illustrates an example of mobile phone number preprocessing according to an embodiment of the present disclosure. Figure 7 A schematic block diagram of a mobile phone number management device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0017] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0018] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0019] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0020] <Method Implementation> Figure 1 A flowchart of a mobile phone number management method according to an embodiment of the present disclosure is shown. Specifically, it includes: step S100, obtaining an encryption key for the mobile phone number to be encrypted from a key library, and encrypting the mobile phone number using the encryption key to generate encrypted mobile phone number data; step S200, constructing an index for the encrypted mobile phone number data, and synchronously storing the encrypted mobile phone number data and the index.

[0021] Therefore, this disclosure provides a mobile phone number management method. It involves obtaining the encryption key for the mobile phone number to be encrypted from a key store, encrypting the mobile phone number using this key to obtain ciphertext data, building an index on the ciphertext data, and storing both the ciphertext data and the index. Compared to traditional methods where encrypted mobile phone number ciphertext cannot directly participate in index construction or fuzzy matching, this technical solution enables index construction of ciphertext mobile phone numbers and further achieves efficient fuzzy search of ciphertext mobile phone numbers without exposing the original mobile phone number, thus improving system availability.

[0022] It should be noted that, in the technical solution of this application, the encryption key used to encrypt the mobile phone number is stored in the key library in an encrypted manner. By encrypting and storing the encryption key for encrypting the mobile phone number, the security of the encryption key is ensured, which further prevents the encryption key from being leaked, thereby improving the security of the encrypted storage of the mobile phone number.

[0023] In one possible implementation, the encryption key can be stored in the keystore in the following way: First, obtain the randomly generated initial dynamic key and the encryption key to be stored. Specifically, randomly generate an initial dynamic key of a preset length and obtain the encryption key to be stored. The preset length of the initial dynamic key can be set to 32, 64, or 128 bits according to actual needs, and its generation process is completely random to ensure the randomness of the initial dynamic key. The encryption key to be stored is the encryption key used in subsequent encryption and decryption operations on the mobile phone number. In one possible implementation, this encryption key is a randomly generated 16-bit random string composed of numbers and uppercase and lowercase letters.

[0024] Then, the initial dynamic key and the encryption key are combined to generate a new dynamic key. Specifically, the combination of the initial dynamic key and the encryption key is done through character substitution. That is, the encryption key is added to the initial dynamic key to replace some characters in the initial dynamic key, thereby achieving the combination of the encryption key and the initial dynamic key.

[0025] In this process, when adding the encryption key to the initial dynamic key to replace some characters in the initial dynamic key, it is necessary to first determine the replacement position of the encryption key in the initial dynamic key. This replacement position is a pre-set fixed position or a fixed interval (such as every N characters). That is, in the technology of this application, the replacement position is pre-set during the design and development process, and the pre-set replacement position is not stored, which effectively prevents the leakage of the replacement position.

[0026] Then, the characters of the initial dynamic key at the replacement position are directly replaced with the characters of the encryption key. By merging the encryption key into the initial dynamic key, and then encrypting the generated dynamic key a second time to obtain the final key, the final key is stored in the key store. In this way, compared with the conventional method of directly storing the encryption key, the encryption key is stored in an indirect encryption method, which avoids the direct exposure of the encryption key.

[0027] The following is combined with Figure 2 The dynamic key generation flowchart combines the initial dynamic key and the encryption key to generate the dynamic key, including: Step S110: Randomly generate a 64-bit dynamic key; Step S120: Obtain the preset real AES key, that is, obtain the encryption key to be stored. Step S130: Obtain the replacement position of the current encryption key to be stored in the initial dynamic key; Step S140: Replace the character at the specified position of the initial dynamic key with the character of the encryption key according to the replacement position.

[0028] To further illustrate the dynamic key generation process described above, the following section will combine... Figure 3 The example of generating a dynamic key will be explained again. For example... Figure 3 As shown: Step S110': Randomly generate a 64-bit dynamic key "azJ24QCvMrAuv471rZj91yuaEthyQynukRAvk8j3kuvANH4EUOCBFguKKZBwh6JU"; Step S120': Obtain the preset real AES encryption key "k3js0h8x"; Step S130': Obtain the replacement position of the current encryption key to be stored in the initial dynamic key {5,8,14,20,35,46,50,58}. Step S140': Based on the replacement position, replace the characters at the specified positions of the initial dynamic key with the characters of the encryption key to obtain the dynamic key "azJ24kCv3rAuv4jlrZj9syuaEthyQynukRAOk8j3kuvANHhEU08BFguKKZxwh6JU". Furthermore, after obtaining the aforementioned dynamic key, when encrypting the fused dynamic key to obtain the final key, an asymmetric encryption algorithm can be used to encrypt the dynamic key. It should be noted that encrypting the dynamic key using an asymmetric encryption algorithm generates not only the final key but also a corresponding asymmetric private key. Both the final key and the corresponding asymmetric private key are then stored as data in a keystore. The asymmetric encryption algorithm can be RSA, SM2, ECC, etc. It should also be noted that when storing the asymmetric private key as data in the keystore, it should be encoded before storage. This prevents the asymmetric private key from being maliciously read and cracked. The encoding of the asymmetric private key can include Base64 encoding and obfuscation.

[0029] Therefore, the mechanism of combining the encryption key with a randomly generated initial dynamic key and then protecting it with an asymmetric encryption algorithm each time the encryption key is stored makes the key storage more secure.

[0030] When retrieving the encryption key for the current phone number to be encrypted from the keystore and using that key to encrypt the phone number to generate ciphertext data, it is necessary to decrypt the encryption key for the current phone number to be encrypted from the final key stored in the keystore, and then use that final key to encrypt the phone number again. In other words, when selecting the corresponding encryption key from the keystore for the current phone number to be encrypted, the selected data is the final key from the keystore.

[0031] In other words, when obtaining the encryption key for the current phone number to be encrypted from the key store and encrypting the phone number using the encryption key, the process includes: First, obtaining the final key corresponding to the current phone number to be encrypted, and the asymmetric private key corresponding to the final key from the key store. Then, decrypting the final key using the asymmetric private key to obtain the dynamic key.

[0032] In selecting a matching final key for the current mobile number, one possible implementation is that different mobile numbers can use the same final key or different final keys; no specific limitation is made here.

[0033] After selecting a matching final key, it can be decrypted to obtain an encryption key. Then, the decrypted encryption key is used to encrypt the phone number.

[0034] For details, see Figure 4 The diagram illustrates the decryption logic for the final key. First, in step S210, the RSA asymmetric private key is decoded using Base64. Since the RSA asymmetric private key is first Base64 encoded and obfuscated during storage, after obtaining the RSA asymmetric private key from the keystore, it needs to be decoded using Base64 to obtain the actual RSA asymmetric private key.

[0035] Then, in step S220, the dynamic key is obtained by decrypting the RSA asymmetric private key. Specifically, the final key obtained from the keystore is decrypted using the real asymmetric RSA private key to obtain the dynamic key.

[0036] Finally, step S230 is used to parse the real AES symmetric key (i.e., the encryption key used to encrypt and decrypt the phone number) from the dynamic key. It should be noted that parseting the encryption key from the dynamic key specifically includes determining the character replacement positions in the dynamic key. These character replacement positions are the positions where the encryption key was replaced within the initial dynamic key during the aforementioned encryption key storage process.

[0037] Extract the characters at the positions where the dynamic key is replaced; the characters at the positions where the final key is replaced are the encryption key.

[0038] After decrypting the final key to obtain the encryption key using the above method, step S240 can be executed to perform AES symmetric encryption using the encryption key. That is, the encryption key is used to perform AES symmetric encryption on the mobile phone number to be encrypted. The AES symmetric encryption algorithm can also be other symmetric encryption algorithms such as SM4 or 3DES to ensure encryption efficiency and security.

[0039] Therefore, this method of using a multi-layered encryption mechanism to encrypt and store the encryption key, and then using a corresponding multi-layered decryption mechanism to recover the encryption key, makes the encrypted storage of mobile phone numbers more secure.

[0040] After encrypting the phone number using the above method, the ciphertext of the phone number is obtained and then stored. In one possible implementation, the storage of the ciphertext includes the process of building a phone number index, so that each stored ciphertext phone number corresponds to a specific index. This allows for direct retrieval and matching of the ciphertext phone number during subsequent queries.

[0041] Specifically, the following methods can be used to build a mobile phone number index: First, the plaintext mobile phone number is fragmented into multiple data segments. This fragmentation can be performed according to preset rules, resulting in multiple data segments (e.g., the first three digits, the middle four digits, and the last four digits). It should be noted that the preset rules are flexible and can be adjusted, such as "7-4", "3-4-4", "2-3-6", etc. The preferred method is fragmentation of the first 7 digits + the last 4 digits. Since the first 3 digits of a mobile phone number indicate the carrier and the middle 4 digits represent the area code, the first 7 digits are sufficient to determine the location. However, in business scenarios, there are instances where queries are performed based on the last 4 digits of the mobile phone number, so the last four digits are also stored. This fragmentation approach allows for the creation of separate indexes for each number segment, enabling fuzzy matching queries on the encrypted mobile phone number and supporting the expansion of multi-dimensional search rules, thus improving usability.

[0042] Then, a hash operation is performed on each data slice to generate a hash value for each data slice, and this hash value is used as the index of the data slice. The hash operation can use functions such as SHA-1, MD5, and SM3. It should be noted that the hash operation on each data slice includes the following steps: 1. Obtain a randomly generated perturbation factor. The perturbation factor can be generated using any of the following methods: user ID, timestamp, application random number, or mobile phone number byte array. Specifically, taking the mobile phone number byte array method as an example, first, obtain the byte array result of the mobile phone number according to the SHA-256 algorithm. Then, traverse the byte array. Next, convert the bytes to integers using bitwise operations hashBytes[i]&0xFF. Then, take the modulo of each byte in the byte array with the preset string constant length to obtain an index. Then, take the character corresponding to the index from the preset string constant. Finally, concatenate the obtained characters corresponding to the index to obtain the perturbation factor. The preset string constant is custom-defined, with a value of "BCFIJKLNOPQRSTUVWXYZbcdefgijklmoqrtuvwxyz0123456789". Furthermore, the preferred length of this perturbation factor is 5 bits. To more clearly illustrate how to obtain the perturbation factor from a phone number byte array, consider the following example: Phone number: 15928418229. After SHA-256 processing, the resulting byte array is [-22,-18,30,11,-5,-40,-63,-32,0,112,-125,-63,-28,-93,-2,88,49,66,99,60,49,32,-125,25,-86,-90,-7,18,-127,35,-19,-32]. Then, the array is iterated through 5 times, and a 5-digit fixed perturbation factor, mtmR6, is obtained from the preset string constant. For the specific implementation of generating the perturbation factor, please refer to the following code: private static String addFixedRandomCode(String str, String mobile)throws NoSuchAlgorithmException { StringBuilder result = new StringBuilder(str); byte[] hashBytes = hashPhone(mobile); for (int i = 0; i <RANDOM_CODE_LENGTH; i++) { int index = (hashBytes[i]&0xFF) % Constants.getRandomMap().length; result.append(Constants.getRandomMap()[index]);} return result.toString(); } 2. Combine the perturbation factor with the data slice to generate index features; the combined index features are unique because they incorporate a randomly generated perturbation factor.

[0043] For example, if the plaintext mobile phone number 15928418229 is fragmented according to the 7-4 fragmentation rule, the resulting data fragments will contain "1592841" and "8229". Since the last four digits of the data fragment "8229" are relatively short, a rule can be set to keep the hash value of numbers with a length of less than 5 digits the same as the plaintext. That is, the hash value of the last four digits of 8229 is still 8229. No perturbation factor is added to this part and no hash operation is performed. Then, only the first 7 bits of data "1592841" are used to generate perturbation factors according to the above method. That is, the byte array [87, -56, -8,120, 32, 77, -99, 95, 126, 72, 21, 117, 11, -11, 51, -39, -76, 36, 41, 50, -21, -3, -14, -16, -57, -81, 28, 40, -3, -47, 19, 30] is obtained by using the same method as above to obtain perturbation factors. Then, the byte array is traversed 5 times to obtain a 5-bit fixed perturbation factor "v63Yq" from the preset constant string.

[0044] In one possible implementation, the first 7 digits of the phone number "1592841" are first shifted to obtain "1482951". Then, the shifted "1482951" is mapped to a fixed character set. The characters corresponding to each digit in the mapped string are concatenated to obtain "pHEGnAp". This "pHEGnAp" string is then concatenated with the generated perturbation factor "v63Yq" to obtain the 12-digit string "pHEGnApv63Yq". Finally, an obfuscation algorithm is used to shuffle the strings to obtain "pHpvGAYq36nE". At this point, the index features of the two shards generated according to the 7-4 sharding rule for the original mobile number 15928418229 have been obtained, which are "pHpvGAYq36nE" and "8229" respectively.

[0045] 3. Perform a hash operation on the index features to obtain the hash value.

[0046] In other words, when hashing the index features to obtain hash values, a perturbation factor is first randomly generated for each data segment. Then, each data segment is combined with its corresponding perturbation factor to obtain the index feature corresponding to each data segment. Next, a hash operation is performed on each index feature to obtain the hash value corresponding to each data segment. Finally, the hash values ​​corresponding to each data segment are stored in independent index tables according to the order of the phone number segments. Furthermore, while encrypting the phone number to obtain the ciphertext, the hash value of the complete phone number is also obtained. The ciphertext and the hash value of the complete phone number are associated and stored in the encryption master table. Then, the hash value of the complete phone number is associated with the hash values ​​corresponding to each data segment and stored in independent index tables according to the segment order. Thus, a phone number ciphertext index system supporting multi-dimensional fuzzy retrieval is constructed, supporting encrypted reverse lookup and collision verification mechanisms for fuzzy matching results. It should be noted that since the hash values ​​of the phone number fragments and the complete phone number hash values ​​are stored in separate index tables, when performing a fuzzy search, the queried phone number fragment is first hashed to obtain its hash value. Then, the associated complete phone number hash value is retrieved based on the phone number fragment's hash value. Because each business table stores the complete phone number hash value, reverse lookups are possible. Since phone numbers are unique, this solution further ensures the uniqueness and stability of each phone number by adding perturbation factors.

[0047] Therefore, by sharding encrypted phone numbers and then building an index, fuzzy matching retrieval can be supported in the encrypted state of the phone number, avoiding the risk of plaintext phone number leakage, improving the system's query performance, and making it more suitable for high-frequency query business scenarios.

[0048] In addition, see Figure 5As shown, when constructing a hash index for a mobile phone number, the preprocessing of the mobile phone number can be performed in another way. First, in step S310, the mobile phone number is shifted using a reverse order algorithm. Then, in step S320, each digit of the mobile phone number is mapped to a fixed character set. It should be noted that the fixed character set is a preset fixed-length mapping string containing uppercase and lowercase letters and numbers, with a length greater than 10 characters. The characters corresponding to each digit of the mobile phone number in the mapping string are concatenated together to obtain a fixed mapping character set. Next, in step S330, a fixed-length random code is added to the end. The fixed-length random code is customized according to actual needs; more digits result in higher security, but also increase the pressure on database storage and business queries. Furthermore, the fixed-length random code is preferably 5 digits, plus the 11 digits of the mobile phone number, for a total of 16 digits, a moderate length that ensures both storage security and database storage and query performance. Moreover, the random code can be a combination of at least one of numbers, uppercase letters, and lowercase letters. Finally, step S340 involves obfuscation and shuffling the order. This obfuscation and shuffling is a random operation; that is, the phone number, after having a fixed-length random code added, is randomly shuffled to obtain new phone number data.

[0049] Next, a hash operation is performed on the preprocessed phone number data to obtain the hash value of the complete phone number. In one possible implementation, after obtaining the hash value of the complete phone number, the same method described above is used to shard the phone number, and then a hash operation is performed on each data shard to obtain the corresponding hash value. This process will not be elaborated further here. Finally, the hash value of the complete phone number and the corresponding hash values ​​of each data shard are associated and stored in an independent index table. Here, the introduction of a 16-bit phone number hash index enables fast location of the encrypted phone number, reduces full table scans, and improves system response speed. The hash algorithm can use MD5, SHA256, etc., or be enhanced with perturbations based on existing algorithms to ensure the uniqueness and stability of the hash value, while avoiding the risk of phone number leakage and further improving query performance and system availability.

[0050] It should be noted that after building an index using the encrypted phone number as described above, when querying an encrypted phone number, the returned encrypted phone number can be decrypted using AES to confirm the phone number, avoiding false hits caused by hash collisions. The custom hash algorithm described above ensures the uniqueness and stability of the hash value. Because it is achieved through shifting, mapping, adding a fixed random code, and obfuscation, the uniqueness of each phone number is guaranteed throughout the process, thus avoiding the possibility of hash collisions.

[0051] To more clearly illustrate the preprocessing process for the aforementioned mobile phone numbers, the following will combine... Figure 6 Here's an example of mobile phone number preprocessing, explained again. For example... Figure 6 As shown: Step S310': The mobile phone number is shifted using a reverse order algorithm to convert the mobile phone number "15922609291" into "19290622951"; Step S320': Map each digit of the mobile phone number to a character in a fixed character set, mapping "19290622951" to "BJCJAGCCJFB"; Step S330': Add a fixed-length random code to the end to convert "BJCJAGCCJFB" to "BJCJAGCCJFBponwW"; Step S340': Obfuscation process to shuffle the order, that is, obfuscate "BJCJAGCCJFBponwW" to "WABJCBvFCGJnoCJp".

[0052] Furthermore, after encrypting and storing the phone number using any of the above methods, when a user's query command is received, the system can match the corresponding index based on the user's query command, then find the corresponding encrypted phone number based on the matched index, and finally decrypt the encrypted phone number. It should be noted that the decryption logic for the encrypted phone number is consistent with the encryption logic principle described above, and will not be repeated here.

[0053] It should be noted that when matching the corresponding index based on the user's query command, the user's query command should contain mobile phone number information. Therefore, the hash value can be directly calculated based on the user's input mobile phone number information, such as the complete mobile phone number or the first 7 digits, and then used for index matching. Specifically, this includes: When the user enters a complete mobile phone number, the system first calculates the complete hash value of the complete mobile phone number, then retrieves the ciphertext of the mobile phone number from the ciphertext master table based on the relationship between the complete hash value and the ciphertext of the mobile phone number, and finally obtains the plaintext of the mobile phone number according to the mobile phone number decryption process.

[0054] When the user enters the first 7 digits of their mobile phone number, the hash value of the first 7 digits is calculated. Then, the associated complete mobile phone number hash value is obtained from an independent index table that stores segmented hash values. Next, the ciphertext of the mobile phone number is obtained from the ciphertext main table based on the complete mobile phone number hash value. Finally, the plaintext mobile phone number is obtained according to the ciphertext decryption process. If the plaintext mobile phone number is not needed in the business, since the complete mobile phone number hash value is also stored in the business table, the data can be directly queried from the various business tables after obtaining the complete hash value, without the need for the ciphertext query and decryption process.

[0055] In another possible implementation, when obtaining the encryption key for the phone number to be encrypted from the keystore and encrypting the phone number using the encryption key, the following steps are also included: The system obtains the permission level data of the mobile phone number, selects different encryption keys for different permission levels, and uses these keys to encrypt the mobile phone number at different permission levels, generating encrypted mobile phone number data for each permission level. The permission level data refers to the user's permission level; that is, there is a one-to-one correspondence between the mobile phone number's permission level and the user's permission level. Specifically, user permissions include at least one of low-level, medium-level, and high-level permissions. Therefore, the mobile phone number's permission level can be set to at least one of these three levels. Each access level is assigned a unique AES key; that is, different permission levels for the same mobile phone number correspond to a unique AES key. Thus, when the system encrypts data at different mobile phone number levels, it generates encrypted mobile phone number data for the corresponding permission level.

[0056] In one possible implementation, the permission level of a mobile phone number is determined by the number of plaintext digits the user can see. For example, high-level permission allows viewing the first 11 digits of the phone number in plaintext; medium-level permission only allows viewing the first three and last four digits, with the middle four digits displayed in plaintext. Subnetting; low-level privileges can only view the last four bits of plaintext, the first seven bits are masked; Number masking: For these three different permission levels, we will assign them separate AES keys. That is, high-level permission, medium-level permission, and low-level permission will each correspond to a dedicated and independent AES key. In this way, different permission levels can select different AES keys, and then use different AES encryption keys to encrypt the mobile number under different permission levels, generating encrypted mobile number data under different permission levels.

[0057] It should be noted that when encrypting a phone number at different permission levels, the same phone number is encrypted three times using the dedicated AES key for each permission level, generating three ciphertexts corresponding to different permission levels. Specifically: when generating the ciphertext for a high-level permission phone number, the dedicated AES key for high-level permissions is used directly to encrypt the complete 11-digit plaintext phone number, resulting in the ciphertext data corresponding to high-level permissions; when generating the ciphertext for a medium-level permission phone number, the plaintext phone number is first masked, and the middle four digits are replaced with... Number (e.g., 159 after processing) (8229), then use the intermediate-level privilege-specific AES key to encrypt the processed masked phone number, obtaining the ciphertext corresponding to intermediate-level privileges; when generating the ciphertext for the low-level privileged phone number, first mask the plaintext phone number, replacing the first 7 digits with Number (e.g., after processing) (4123), then use the low-level privilege exclusive AES key to encrypt the processed masked phone number to obtain the ciphertext corresponding to the low-level privilege.

[0058] Next, when storing the encrypted phone numbers corresponding to different permissions, based on the generation logic of the encrypted data for different permission levels, only two fields need to be added to the existing encrypted main table storing the encrypted phone numbers. These fields will store the encrypted phone numbers for medium-level and low-level permissions, respectively. The encrypted phone numbers for high-level permissions will remain stored in the existing corresponding fields without needing additional additions. This simplifies the storage logic and clearly identifies the encrypted data after encryption with keys for different permission levels. In one possible implementation, when storing and building hash indexes for the encrypted phone numbers corresponding to different permissions, the same hash algorithm is used to build indexes for phone numbers at different permission levels. This ensures that phone numbers at different permission levels are associated with the same hash index, thus not affecting normal business queries.

[0059] It should be noted that the encryption keys and ciphertexts corresponding to different permission levels can be precisely controlled and used through the internal permission management system. For example, when an internal user (such as a salesperson) creates an account, they are assigned a corresponding role and corresponding data permissions (i.e., user access permissions). We associate user roles with plaintext phone number viewing permissions, and then associate them with the corresponding AES keys for the corresponding access permissions. When a user logs into the internal system to view a student's phone number, the system first obtains all of the user's data permissions, determines their corresponding phone number viewing permission level (high / medium / low), then matches and obtains the AES key specific to that permission level, and finally uses this key to decrypt the ciphertext corresponding to the permission level, allowing the user to only view the phone number content within their permission scope (i.e., the highest permission allows viewing the complete plaintext, and medium / low permissions allow viewing the corresponding masked phone number), ensuring the standardized use of keys at different permission levels and data security.

[0060] In one possible implementation, different masking rules are used when encrypting the phone number using an encryption key. It should be noted that these different masking rules are set based on preset user access permissions. For example, users with lower access permissions can only see the first three digits of the phone number plus the mask, users with medium access permissions can see the first three digits and the last four digits plus the middle four-digit mask, and users with high access permissions can see the complete plaintext phone number.

[0061] In addition, it should be noted that the results displayed after decrypting the encrypted phone number are based on access permission levels, including: First, obtain the user access permission level and corresponding key of the person decrypting the data; Then, based on the access level of the person decrypting the data, the corresponding phone number mask or plaintext result is obtained.

[0062] It should be noted that user access permission levels can be set according to actual business needs, such as: low-level permissions, medium-level permissions, and high-level permissions. Specifically: When a user with low privileges performs a decryption operation, the AES encryption key corresponding to the user with low privileges can be obtained. After decrypting the phone number using the low-privilege AES encryption key, the result is displayed as: the first three digits of the phone number + the last eight digits of the mask.

[0063] When an intermediate-level user performs a decryption operation, the corresponding AES encryption key of the intermediate-level user can be obtained. After decrypting the phone number using the intermediate-level AES encryption key, the result is displayed as: the first three and last four digits of the phone number + the middle four-digit mask.

[0064] When a user with advanced privileges performs a decryption operation, the user can obtain the AES encryption key corresponding to the user with advanced privileges. After decrypting the phone number using the advanced privilege AES encryption key, the result is displayed as the complete plaintext phone number.

[0065] By employing a tiered decryption method using mobile phone numbers, users with different permissions can only obtain keys and mobile phone number information within the authorized scope, thus avoiding the risk of full data leakage.

[0066] Therefore, this disclosure provides a mobile phone number management method. It involves obtaining the encryption key for the mobile phone number to be encrypted from a key store, encrypting the mobile phone number using this key to obtain ciphertext data, building an index on the ciphertext data, and storing both the ciphertext data and the index. Compared to traditional methods where encrypted mobile phone number ciphertext cannot directly participate in index construction or fuzzy matching, this technical solution enables index construction of ciphertext mobile phone numbers and further achieves efficient fuzzy matching of ciphertext mobile phone numbers without exposing the original mobile phone number, thus improving system availability.

[0067] <Device Embodiment> According to an embodiment of the present disclosure, a mobile phone number management device includes: a mobile phone number encryption module, configured to obtain an encryption key for a mobile phone number to be encrypted from a key library, and encrypt the mobile phone number using the encryption key to generate encrypted mobile phone number data; and an index building module, configured to build an index for the encrypted mobile phone number data, and synchronously store the encrypted mobile phone number data and the index.

[0068] <Equipment Example> Figure 7 A schematic block diagram of a mobile phone number management device according to an embodiment of the present disclosure is shown. Figure 7 As shown, the mobile phone number management device 200 includes a processor 210 and a memory 220 for storing executable instructions of the processor 210. The processor 210 is configured to implement any of the aforementioned mobile phone number management methods when executing the executable instructions.

[0069] It should be noted here that the number of processors 210 can be one or more. Furthermore, the mobile phone number management device 200 in this embodiment may also include an input device 230 and an output device 240. The processors 210, memory 220, input device 230, and output device 240 can be connected via a bus or other means, without specific limitations here.

[0070] The memory 220, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and various modules, such as the program or module corresponding to the mobile phone number management method of this disclosure embodiment. The processor 210 executes various functional applications and data processing of the mobile phone number management device 200 by running the software program or module stored in the memory 220.

[0071] Input device 230 can be used to receive input digital numbers or signals. These signals may be key signals related to user settings and function control of the device / terminal / server. Output device 240 may include a display device such as a screen.

[0072] <Storage Medium Examples> According to a fourth aspect of this application, a non-volatile computer-readable storage medium is also provided, on which computer program instructions are stored, which, when executed by processor 210, implement any of the preceding mobile phone number management methods.

[0073] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for managing mobile phone numbers, characterized in that, Used for encrypted storage of mobile phone numbers, including: Obtain the encryption key for the current mobile phone number to be encrypted from the key store, and use the encryption key to encrypt the mobile phone number to generate encrypted mobile phone number data; An index is built on the encrypted mobile phone number data, and the encrypted mobile phone number data and the index are stored synchronously.

2. The method according to claim 1, characterized in that, When storing the encryption key in the key store, it is stored in the following manner: Obtain the randomly generated initial dynamic key and the currently stored encryption key; The initial dynamic key and the encryption key are combined to generate a dynamic key; The dynamic key is encrypted using an asymmetric encryption algorithm to generate a final key, which is then stored in the key repository as storage data.

3. The method according to claim 1, characterized in that, When obtaining the encryption key for the current mobile phone number to be encrypted from the key store, and encrypting the mobile phone number using the encryption key, the method further includes: Obtain the permission level data of the mobile phone number, select different encryption keys for different permission levels, and use different encryption keys to encrypt the mobile phone number under different permission levels to generate encrypted mobile phone number data under different permission levels.

4. The method according to claim 1, characterized in that, When encrypting the mobile phone number using the encryption key, different masking rules are used for encryption processing.

5. The method according to any one of claims 1 to 4, characterized in that, When building an index for the encrypted mobile phone number data, the following steps are included: The mobile phone number is segmented to obtain multiple data segments of the mobile phone number; A hash operation is performed on each of the data slices to generate a hash value for each data slice, and the hash value is used as an index for the data slice.

6. The method according to claim 5, characterized in that, When performing hash operations on each of the aforementioned data slices, the following are included: Obtain the randomly generated perturbation factor; The perturbation factor is combined with the data slice to generate index features; The hash value is obtained by performing a hash operation on the index feature.

7. A mobile phone number management device, characterized in that, Used for encrypted storage of mobile phone numbers, including: Mobile phone number encryption module: Obtains the encryption key for the mobile phone number to be encrypted from the key library, and uses the encryption key to encrypt the mobile phone number to generate encrypted mobile phone number data; Index building module: Builds an index on the encrypted mobile phone number data, and stores the encrypted mobile phone number data and the index synchronously.

8. A mobile phone number management device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method of any one of claims 1 to 6 when executing the executable instructions.

9. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images