Method, system and device for encrypting and decrypting user identification in data

Abstract

Embodiments of the present application provide a method, system and device for encrypting and decrypting user identification in data. The encryption method comprises: obtaining target data to be sent to a data user and information of the data user; determining reference information based on preset scene configuration information; determining a key according to the reference information and the information of the data user; encrypting a user identification in the target data using the key to obtain encrypted information; and generating an encrypted identification corresponding to the user identification according to the reference information and the encrypted information. The scheme provided by the embodiments of the present application uses an encrypted identification to replace a plaintext user identification provided to a data user, which meets the needs of an open scene and eliminates the risk of using a user identification associated with user personal information by black and gray production.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a method, system and device for encrypting and decrypting user identification in data. BACKGROUND

[0002] In recent years, external black and gray production frequently crawls and attacks user identification. They can contact the corresponding user based on user identification through various means, and implement criminal behaviors such as fraud, cheating, malicious marketing, etc. In order to reduce such risks, it is necessary to encrypt the plaintext user identification (such as user ID, nickname, etc.).

[0003] The existing user identification encryption scheme has low security. SUMMARY

[0004] The present application provides a method, system and device for encrypting and decrypting user identification in data to improve security.

[0005] In an embodiment of the present application, a method for encrypting user identification in data is provided. The method comprises:

[0006] obtaining target data to be sent to a data user and information of the data user;

[0007] determining reference information and service object identification based on the information of the data user;

[0008] determining a key according to the reference information and the information of the data user;

[0009] encrypting user identification in the target data using the key to obtain encrypted information;

[0010] generating an encrypted identification corresponding to the user identification according to the reference information and the encrypted information.

[0011] In another embodiment of the present application, a method for decrypting user identification in data is provided. The method comprises:

[0012] obtaining information of a data user and encrypted identification in target data; wherein the data user has the right to use the target data;

[0013] parsing the encrypted identification to obtain reference information and encrypted information;

[0014] determining a key according to the reference information and the information of the data user;

[0015] decrypting the encrypted information using the key to obtain user identification corresponding to the encrypted identification.

[0016] In another embodiment of this application, a data service system is provided. The system includes:

[0017] The data provider stores the data;

[0018] The data processing subsystem has an open platform that provides APIs;

[0019] Data users access the data processing subsystem via the API to obtain data stored at the data provider's location through the data processing subsystem.

[0020] The data processing subsystem is configured to: acquire target data to be sent to a data user and information about the data user; determine reference information and service object identifier based on the information about the data user; determine a key based on the reference information and the information about the data user; encrypt the user identifier in the target data using the key to obtain encrypted information; and generate an encrypted identifier corresponding to the user identifier based on the reference information and the encrypted information.

[0021] This application also provides an embodiment of a computing device, which includes a memory and a processor. The memory stores one or more computer instructions. The processor is coupled to the memory and is used to execute the one or more computer instructions to implement steps in the encryption method of the user identifier in the aforementioned data, or steps in the decryption method of the user identifier in the aforementioned data.

[0022] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform steps in the encryption method for the user identifier in the aforementioned data, or steps in the decryption method for the user identifier in the aforementioned data.

[0023] Another embodiment of this application provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to perform steps in the encryption method for the user identifier in the aforementioned data, or steps in the decryption method for the user identifier in the aforementioned data.

[0024] The technical solutions provided in the embodiments of this application propose a user identifier encryption and decryption scheme for open scenarios, under the background of user personal data protection and data security. The schemes provided in the embodiments of this application use encrypted identifiers instead of plaintext user identifiers provided to data users, meeting the requirements of open scenarios while eliminating the risk of black market actors using user identifiers to associate them with user personal information. The schemes provided in the embodiments of this application determine the reference information for obtaining the key based on preset scenario configuration information; different isolation and interoperability levels can be configured for different service scenarios, thereby controlling the flow of user data between different service objects; it can effectively prevent cracking and is difficult to use to match user personal information; it can support rapid key rotation and updates to further address potential leakage situations. Attached Figure Description

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

[0026] Figure 1 A schematic diagram illustrating the principle of a user identification encryption method in the prior art is shown;

[0027] Figure 2 A flowchart illustrating a method for encrypting user identifiers in data provided in this application is shown.

[0028] Figure 3 A flowchart illustrating a method for decrypting a user identifier in data according to an embodiment of this application is shown.

[0029] Figure 4 This illustration shows a schematic diagram of the principle corresponding to the encryption method for user identifiers in data provided in an embodiment of this application;

[0030] Figure 5 A schematic diagram of the structure of a data processing system provided in an embodiment of this application is shown;

[0031] Figure 6 This invention provides a structural block diagram of an encryption device for user identification in data according to an embodiment of the present application.

[0032] Figure 7 This invention provides a structural block diagram of a device for decrypting user identifiers in data according to an embodiment of the present application.

[0033] Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0034] Figure 1 This paper illustrates a prior art scheme for encrypting user identifiers in data. Figure 1 In this context, KeyCenter (Key Management Center) is the key management center.

[0035] KC Issuance Code: Maintained through KeyCenter, used to identify the user of the KC key.

[0036] KC Key: An encryption key obtained through KeyCenter. Users can use the KC distribution code and KC key to encrypt and decrypt user identifiers via KeyCenter's SDK (Software Development Kit).

[0037] In the encryption process, existing technologies use symmetric encryption, meaning that the same KC key is used for both encryption and decryption.

[0038] Figure 1 The prior art shown has the following disadvantages:

[0039] 1. In practice, KC keys and KC issuance codes must be applied for manually and require a machine restart. Automated application and runtime hot reloading are not supported.

[0040] 2. User identifiers encrypted with the same KC key are still essentially unique user identifiers. Although encrypted identifiers offer some security compared to plaintext user identifiers, malicious actors can easily establish a correspondence between these encrypted identifiers and users.

[0041] 3. The risk of KC key leakage is high. If key rotation and updates are required, all external encryption codes will become invalid, resulting in a wide-ranging impact.

[0042] 4. The encrypted identifier is quite long and the length is not fixed. ISVs (Independent Software Vendors) need to modify their respective databases for maintenance.

[0043] Therefore, this application provides the following embodiments, employing a scheme with higher encryption security and better isolation to improve the problems existing in the prior art. To enable those skilled in the art to better understand the solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0044] In some processes described in the specification, claims, and accompanying drawings of this application, multiple operations appearing in a specific order are included. These operations may be executed out of order or in parallel. Operation numbers such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types. The term "or / and" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A or / and B means that A can exist alone, A and B can exist simultaneously, or B can exist alone. The character " / " in this application generally indicates that the preceding and following related objects have an "or" relationship. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system including said element. Furthermore, the following embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0045] Before introducing the various embodiments of this application, a brief background of the solution is provided. The inventors of this application have discovered that in current open environments, such as open platforms, open platforms provide API interfaces and related development environments. This allows third-party application developers to develop third-party tools based on the open platform to provide to e-commerce merchants or buyers; merchants' own management systems can also obtain their own order information through API interfaces for corresponding statistical management, etc. Third-party application developers' tools, merchant management systems, etc., can obtain data from the open platform's backend database through APIs. For example, the data stored in the backend database is data from the e-commerce platform, such as buyer user information, seller user information, product information, store information, product category information, product transaction information, etc.

[0046] Ideally:

[0047] Scenario 1: A third-party application developer's first, second, and third tools access a backend database via API to obtain data 1, data 2, and data 3, respectively. Assume that data 1, data 2, and data 3 all belong to user A (e.g., a member or registered user) on the same e-commerce platform. The third-party application developer cannot aggregate the user data obtained from different tools; that is, user data between different tools is not interoperable.

[0048] Scenario 2: User data cannot be shared between different tools developed by different third-party application developers.

[0049] Scenario 3: A merchant has multiple stores, each with its own order management tool. Order information from these different tools cannot be shared to prevent the merchant's order management tools from aggregating buyer information across stores.

[0050] By increasing the difficulty of aggregating the same user information and breaking the chain of association, the risk of black and gray market operators using user identifiers to associate with users' personal information can be reduced.

[0051] Therefore, the embodiments of this application provide the following technical solutions to provide encryption and decryption schemes with high security and strong isolation, so as to achieve the above objectives.

[0052] Figure 2 This illustration shows a flowchart of a method for encrypting user identifiers in data according to an embodiment of this application. Figure 2 As shown, the encryption method includes:

[0053] 101. Obtain the target data to be sent to the data user and the information of the data user.

[0054] 102. Determine reference information based on the preset scene configuration information.

[0055] 103. Determine the key based on the reference information and the information of the data user.

[0056] 104. Use the key to encrypt the user identifier in the target data to obtain encrypted information.

[0057] 105. Generate an encrypted identifier corresponding to the user identifier based on the reference information and the encryption information.

[0058] In the above 101, the data user can be an application (APP), management software, etc., and this embodiment does not limit this. Among them, management software may include, but is not limited to: CRM (Customer Relationship Management), merchant order management software, logistics management software, etc.

[0059] The app can be developed by an ISV, or it can be developed by a merchant based on the resources of an open platform, and so on.

[0060] The target data and the information of the data user can be determined through the context of the open platform request. For example, if the data user sends a request to obtain the target data through the open platform, and the data user has the permission to use the target data, the target data is read and sent back to the data user. The request includes the data user's information.

[0061] In one specific embodiment, the information of the data user may include: a tool identifier and a user identifier corresponding to a third-party tool developed based on the open platform. The user identifier may be a developer identifier corresponding to the third-party tool developer or a user identifier corresponding to the third-party tool user. For example, the developer identifier may be an ISVID, etc.; the user identifier may be the name, nickname, etc., of the third-party tool user. The tool identifier may specifically be an AppKey, which is a unique identifier for the tool. The open platform uses the AppKey to identify the application.

[0062] In section 102 above, the scenario configuration information can be manually set. This scenario configuration information can be pre-configured with: version information (such as algorithm version, key version, etc.), and the service scenario type. For example, the current scenario primarily aims to prevent different developers' tools from sharing and aggregating user data. Or, the current scenario aims to prohibit merchant order management tools from aggregating buyer information across stores.

[0063] In practical implementation, each data user can be associated with a scene configuration information. That is, step 102 in this embodiment may include: obtaining the scene configuration information associated with the data user based on the data user's information; and then determining the reference information based on the scene configuration information.

[0064] The reference information may include, but is not limited to, version information, service scenario type, etc. The version information includes at least one of algorithm version information and key version information.

[0065] In a feasible real-time manner, the above-mentioned step 103, "determining the key based on the reference information and the information of the data user," can be implemented using the following steps:

[0066] 1031. Based on the service scenario type, determine the service object identifier from the information of the data user;

[0067] 1032. Determine the key based on the reference information and the service object identifier.

[0068] As mentioned above, the information about the data user includes both a tool identifier and a user identifier. The service scenario type clarifies the specific meaning of these two identifiers. For example, if the current service scenario type is Type 1, which corresponds to a scenario where user data from different developers' corresponding tools cannot be shared or aggregated, then the user identifier in the data user information can be identified as the service object identifier. Similarly, if the current service scenario type is Type 2, which corresponds to a scenario where user data from different tools cannot be shared or aggregated, then the tool identifier in the data user information can be identified as the service object identifier.

[0069] The difference between the first and second types is that the first type restricts data sharing between different developers, while data sharing between multiple tools developed by the same developer is still possible; the second type restricts data sharing between different tools, and even if two tools are developed by the same developer, they cannot share data.

[0070] Additionally, it should be noted that the tool can be an application (APP, such as a mini-program), or management software with corresponding functions, etc. This embodiment does not specifically limit it.

[0071] Accordingly, step 1031 above, "determining the service object identifier from the data user's information based on the service scenario type," may include:

[0072] Based on the service scenario type, at least one identifier is determined from the tool identifier and the user identifier as the service object identifier.

[0073] Furthermore, if one of the tool identifier and the user identifier is determined to be the service object identifier, the other can be used as extended service object information. Of course, the extended service object information can also be a timestamp or pre-set information. That is, the method provided in this application embodiment may further include at least one of the following steps:

[0074] 106. If one of the tool identifier and the user identifier is determined to be the service object identifier, then the other is the service object extended information;

[0075] 107. Obtain timestamp information and use the timestamp information as extended information of the service object;

[0076] 108. Use the preset information as extended information for the service object.

[0077] Thus, the first feasible solution for step 104 above is to directly use the key and the algorithm corresponding to the algorithm version in the reference information to encrypt the user identifier in the target data. The second feasible solution, with the service object extension information, further implements step 104, "encrypting the user identifier in the target data using the key to obtain encrypted information," using the following steps:

[0078] 1041. Encode the user identifier and the service object extended information to obtain first encoded information;

[0079] 1042. Using the key, encrypt the first encoded information to obtain the encrypted information.

[0080] Furthermore, step 103 in this embodiment, "determining the key based on the reference information and the information of the data user," may include:

[0081] 1031' The reference information and the information of the data user constitute the query keywords;

[0082] 1032' Query whether there is a key associated with the query keyword in the local memory;

[0083] 1033' If the key exists in local memory, retrieve it;

[0084] 1034' If not found in local memory, check if there is a key associated with the query keyword in the Redis cache;

[0085] 1035' If the key is present in the Redis cache, retrieve the key;

[0086] 1036' If the key is not found in the Redis cache, query the database for the key associated with the query keyword.

[0087] Based on the above, the query keywords in '1031' can include: the reference information and the service object identifier. More specifically, the query keywords can include: algorithm version information, key version information, service scenario type, and service object identifier.

[0088] In practice, key storage is divided into local memory caching (e.g., 30-second expiration), Redis caching, and persistent database, taking into account both high-concurrency scenarios and timely runtime data updates.

[0089] In addition, this application embodiment may include a key management center (KeyCenter), which generates keys based only on algorithm version information and key version information, encrypts user identifiers, and is not visible to the outside world.

[0090] Furthermore, in this embodiment, step 105, "generating an encrypted identifier corresponding to the user identifier based on the reference information and the encryption information," may include the following steps:

[0091] 1051. Encode the reference information to obtain second encoded information;

[0092] 1052. Place the second encoded information in front of the encrypted information to obtain the encrypted identifier corresponding to the user identifier.

[0093] Figure 3 A flowchart illustrating a method for decrypting user identifiers in data provided in another embodiment of this application is shown. Figure 3 As shown, the decryption method includes:

[0094] 201. Obtain information about the data user and the encrypted identifier in the target data; wherein the data user has the authority to use the target data.

[0095] 202. The encrypted identifier is parsed to obtain reference information and encrypted information.

[0096] 203. Determine the key based on the reference information and the information of the data user.

[0097] 204. Use the key to decrypt the encrypted information to obtain the user identifier corresponding to the encrypted identifier.

[0098] The method provided in this application is the reverse process of the encryption method embodiments described above. The implementation process of this embodiment can be understood in correspondence with the encryption method embodiments described above.

[0099] In one specific embodiment, the encrypted identifier includes a first part of information at the front and a second part of information at the back. The first part of information corresponds to reference information, and the second part of information corresponds to encrypted information. Accordingly, step 202 above, "parse the encrypted identifier to obtain reference information and encrypted information," may include:

[0100] 2021. The first part of the information is parsed to obtain the reference information;

[0101] 2022. The second part of the information is the encrypted information to be decrypted.

[0102] Furthermore, the reference information includes: version information and service scenario type; the version information includes at least one of algorithm version information and key version information; and step 203 of this embodiment, "determining the key based on the reference information and the information of the data user," may include:

[0103] 2031. Based on the service scenario type, determine the service object identifier from the information of the data user;

[0104] 2032. Determine the key based on the reference information and the service object identifier.

[0105] For the specific implementation of 2031 and 2032 mentioned above, please refer to the corresponding steps in the text above, which will not be repeated here.

[0106] Furthermore, step 204 of this embodiment, "decrypting the encrypted information using the key to obtain the user identifier corresponding to the encrypted identifier," may include:

[0107] 2041. Decrypt the encrypted information using the key to obtain the first encoded information;

[0108] 2042. Parse the first encoded information to obtain the parsed information;

[0109] 2043. If the parsed information contains extended service object information, then extract the user identifier from the parsed information;

[0110] If the parsed information does not contain service object extended information, then the parsed information is the user identifier.

[0111] The extended information for service recipients may include, but is not limited to, at least one of the following: identifiers in the information of the data user that are not identified as service recipients, timestamps, pre-set information, etc.

[0112] In summary, this application proposes a user identifier encryption / decryption scheme for open scenarios. The schemes provided in the embodiments of this application are used to encrypt the user identifier in the data, replacing the plaintext user identifier. This satisfies the service requirements of the open platform while reducing the risk of black market actors using user identifiers to associate them with users' personal information.

[0113] The encryption / decryption scheme provided in this application can be configured with different isolation and interoperability levels for different service scenarios, thereby controlling the flow of user data between different service objects (such as ISVs, merchants, etc.), effectively preventing cracking, and making it difficult to use to match user personal information. It also supports rapid key rotation and updates to further address potential leaks.

[0114] Furthermore, the encryption algorithms used in the various embodiments of this application may include, but are not limited to, the AES192 algorithm. The AES192 algorithm is a secure symmetric encryption algorithm using a 192-bit key, and currently there is no effective method to crack it. AES (Advanced Encryption Standard) is a block cipher, belonging to the category of symmetric cryptography. Modules of the AES algorithm are commonly used in the field of symmetric cryptography, especially in the field of block ciphers. The AES encryption algorithm involves four operations: byte substitution (SubBytes), row shifting (ShiftRows), column mixing (MixColumns), and round key addition (AddRoundKey).

[0115] The following is combined Figure 4 The encryption and decryption processes provided in the various embodiments of this application are described below. See also... Figure 4 As shown in the figure:

[0116] Algorithm version: Indicates the current version of the encryption algorithm, used for upgrading the encryption algorithm.

[0117] Key version: Indicates the version to which the current key belongs, used to support key update rotation.

[0118] Service Scenario Type: The open service scenario type that identifies the encrypted identifier (the user identifier that completes the encryption using the scheme provided in the embodiments of this application can be called OpenUid, and OpenUid will be used to represent the encrypted identifier below) is used to clarify the meaning of the service object identifier and the extended information of the service object.

[0119] Service object identifier: Identifies the user of OpenUid, such as AppKey, ISVId, authorized user identifier, etc.

[0120] Extended information for service recipients: This includes additional encrypted content such as timestamps and authorized user identifiers.

[0121] OpenUid: A fixed encoding of 25 characters (e.g., 19 bytes converted using BASE64 RFC4648 URL SAFE), such as: BBCHhIMbva-QL7Dmc_sakKWkW

[0122] Key Management Instructions:

[0123] 1. A combination of algorithm version information, key version information, service scenario type, and service object identifier corresponds to a key, meaning that the key can be retrieved through this combination.

[0124] 2. In practice, the storage of keys is divided into local memory cache (expiring in 30 seconds), Redis cache and persistent database, which takes into account both high concurrency scenarios and timely updates of runtime data.

[0125] 3. KC acts only as an intermediate key, protecting and encrypting the user identifier in the data called remotely, without being perceived by outsiders.

[0126] Encryption process description:

[0127] 1.1 Obtain the user identifier from the target data and convert the user identifier into a numeric type UserID (used to compress and fix the length of OpenUid).

[0128] 1.2 Obtain the AppKey and Authorized User ID through the context of the open platform request.

[0129] 1.3. Based on the pre-configured service scenario information, obtain the algorithm version information, key version information, and service scenario type.

[0130] 1.4. Based on the service scenario type, determine whether one of the AppKey and the authorized user ID is the service object identifier and the other is the service object extended information.

[0131] 1.5. The service scenario type, service object identifier, algorithm version information, and key version information are combined to form the key query parameters.

[0132] 1.6. Query and obtain the key.

[0133] 1.7 Encode the UserID and service object extended information to obtain the second encoded information.

[0134] 1.8. Use the key to encrypt the second encoded information to obtain encrypted information.

[0135] 1.9 Encode the service scenario type, algorithm version information, and key version information to obtain the first encoded information;

[0136] 2.0. Combine the first encoded information with the encrypted information to obtain the OpenUid.

[0137] Decryption process description:

[0138] 2.1 Obtain the AppKey and Authorized User ID through the context requested by the Open Platform.

[0139] 2.2. Parse the first part of OpenUid to obtain the algorithm version, key version, and service scenario type.

[0140] 2.3. Based on the service scenario type, determine whether one of the AppKey and the authorized user ID is the service object identifier and the other is the service object extended information.

[0141] 2.4. The algorithm version, key version, service scenario type, and service object identifier are combined to form the key query parameters.

[0142] 2.5. Obtain the key by querying.

[0143] 2.6. Use the key to decrypt the second half of OpenUid to obtain the numeric UserID.

[0144] 2.7. Convert the numeric UserID to a user identifier.

[0145] As can be seen, the solution provided in this application has the following characteristics:

[0146] A. Because the service object identifier and the key are associated, the encrypted OpenUid for the same user identifier will be different for different service objects. Similarly, because the service object extension information is additional encrypted content, the encrypted OpenUid for the same user identifier will also be different for different extension information for the same service object.

[0147] B. Different OpenUids are encrypted with the same user identifier, which can prevent user data from being directly exchanged between different service objects (such as ISVs, merchants, stores, etc.). This not only greatly increases the difficulty for black and gray market operators to progressively encrypt and encode data and establish correspondences between users, but also reduces the impact of key rotation updates, allowing for separate governance of high-risk service objects.

[0148] The following lists several types of service objects and scenarios for explanation:

[0149] 3.1: The service object identifier is ISVID: User data obtained by tools from different developers cannot be shared.

[0150] 3.2: The service object identifier is AppKey: User data obtained by different tools cannot be shared, which can prevent developers from aggregating user data from different functional tools.

[0151] 3.3: The service object identifier is AppKey, and the service object extended information is the authorized user ID: Data of users from different tools cannot be shared. For example, merchant order management tools can be prohibited from aggregating buyer information across stores.

[0152] 3.4: The service object identifier is a combination of AppKey and authorized user ID: The effect is the same as the previous one (3.3), but the security is higher. Each combination corresponds to a key.

[0153] 3.5: The service object identifier is AppKey, and the extended information of the service object is a timestamp: the user ID is different for each request.

[0154] Of course, the solution in this application embodiment can be adjusted to support data interoperability in some special scenarios by adjusting the service scenario configuration information, such as setting the keys corresponding to two service objects (such as two merchants) to be the same.

[0155] The technical effects of the solutions provided in the various embodiments of this application are as follows:

[0156] 4.1 The key management adopts a multi-layer caching design, which takes into account both high concurrency and timely updates of runtime data, and supports automated key generation and runtime loading of key data.

[0157] 4.2 Design service scenario types, service object identifiers, and service object extended information. Different service objects can be configured with independent keys. Support different isolation and interoperability levels for different service scenarios, thereby controlling the flow of user data between different service objects.

[0158] 4.3 The OpenUid obtained by each service object for the same user identifier is different, which effectively prevents it from being cracked and makes it difficult to be used to match the user's personal information.

[0159] 4.4 Each service object has an independent key that does not affect others and can be governed and managed separately. It supports rapid rotation and key updates to further address the possibility of leakage.

[0160] 4.5 Design a fixed-format encrypted OpenUid with a length of 25 characters. It supports regular expressions to distinguish between OpenUid and plaintext user ID, and its length is shorter than the original plaintext user nickname. ISVs do not need to modify the database or perform various input parameter verifications.

[0161] It is important to note here that: this article focuses on the encryption and decryption of user identifiers in data. In fact, the encrypted object in each embodiment of this application can be other information besides user identifiers, such as some private information that cannot be in plaintext. The solutions provided in each embodiment of this application can be applied to the encryption and decryption of various types of information.

[0162] Figure 5 A schematic diagram of the structure of a data service system provided in one embodiment of this application is shown. Figure 5 As shown, the data service system includes: a data provider 11, a data processing subsystem 12, and a data user 13. Among them,

[0163] Data provider 11 stores data;

[0164] Data processing subsystem 12 has an open platform that provides APIs;

[0165] Data user 13 accesses the data processing subsystem 12 through the API to obtain the data stored at the data provider 11 through the data processing subsystem 12;

[0166] The data processing subsystem 12 is configured to acquire target data to be sent to a data user and information about the data user; determine reference information and service object identifier based on the information about the data user; determine a key based on the reference information and the information about the data user; encrypt the user identifier in the target data using the key to obtain encrypted information; and generate an encrypted identifier corresponding to the user identifier based on the reference information and the encrypted information.

[0167] The data processing subsystem in this embodiment can implement all the steps in the above embodiment of the encryption method for user identifiers in the data. For details, please refer to the corresponding content above, which will not be repeated here.

[0168] Furthermore, the data user 13 is used to obtain information about the data user and the encrypted identifier in the target data; wherein the data user has the right to use the target data; the encrypted identifier is parsed to obtain reference information and encrypted information; a key is determined based on the reference information and the information of the data user; the encrypted information is decrypted using the key to obtain the user identifier corresponding to the encrypted identifier.

[0169] Similarly, the data user in this embodiment can implement all the steps in the above-mentioned data decryption method embodiment, as detailed in the relevant content above, which will not be repeated here.

[0170] The data user can query through the open platform when using reference information and the data user's information query key.

[0171] Figure 6An encryption device for user identifiers in data, according to an embodiment of this application, is illustrated. The encryption device includes: a first acquisition module 21, a first determination module 22, an encryption module 23, and a generation module 24. The first acquisition module 21 acquires target data to be sent to a data user and information about the data user. The first determination module 22 determines reference information based on preset scenario configuration information and determines a key based on the reference information and the data user information. The encryption module 23 encrypts the user identifier in the target data using the key to obtain encrypted information. The generation module 24 generates an encrypted identifier corresponding to the user identifier based on the reference information and the encrypted information.

[0172] Furthermore, the reference information includes: version information and service scenario type; the version information includes at least one of algorithm version information and key version information. Accordingly, when the first determining module 22 determines the key based on the reference information and the data user's information, it is specifically used for:

[0173] Based on the service scenario type, the service object identifier is determined from the information of the data user; based on the reference information and the service object identifier, the key is determined.

[0174] Furthermore, the information regarding the data user includes: the tool identifier and user identifier corresponding to the third-party tool developed based on the open platform; wherein, the user identifier is either the developer identifier corresponding to the third-party tool developer or the user identifier corresponding to the third-party tool user. Accordingly,

[0175] When the first determining module 22 determines the service object identifier from the information of the data user based on the service scenario type, it is specifically used for:

[0176] Based on the service scenario type, at least one identifier is determined from the tool identifier and the user identifier as the service object identifier.

[0177] Furthermore, the encryption device provided in this application embodiment may also include an extended information determination module. This extended information determination module is used for:

[0178] If either the tool identifier or the user identifier is determined to be the service object identifier, then the other is the service object extended information; and / or

[0179] Obtain timestamp information and use the timestamp information as extended information for the service object; and / or

[0180] The pre-set information is used as extended information for the service object.

[0181] Furthermore, when the encryption module uses the key to encrypt the user identifier in the target data to obtain encrypted information, it is specifically used for:

[0182] The user identifier and the service object extension information are encoded to obtain first encoded information; the first encoded information is encrypted using the key to obtain the encrypted information.

[0183] Furthermore, when determining the key based on the reference information and the information of the data user, the first determining module 22 is specifically used for:

[0184] The reference information and the information of the data user constitute the query keywords;

[0185] Check if a key associated with the query keywords exists in the local memory;

[0186] If the key exists in local memory, it can be retrieved.

[0187] If the key is not present in local memory, check if the key associated with the query keyword is in the Redis cache.

[0188] If the key is present in the Redis cache, it can be retrieved.

[0189] If the key is not found in the Redis cache, query the database for the key associated with the query keyword.

[0190] Furthermore, when generating the encrypted identifier corresponding to the user identifier based on the reference information and the encryption information, the generation module 24 is specifically used for:

[0191] The reference information is encoded to obtain second encoded information; the second encoded information is placed before the encrypted information to obtain the encrypted identifier corresponding to the user identifier.

[0192] It should be noted that the encryption device for the user identifier in the data provided in this embodiment can implement the technical solution described in the above embodiment of the encryption method for the user identifier in the data. The specific implementation principle of each module or unit can be found in the corresponding content in the above method embodiment, and will not be repeated here.

[0193] Figure 7 A schematic diagram of the structure of a decryption device for user identifiers in data provided in an embodiment of this application is shown. Figure 7As shown, the decryption device includes: a second acquisition module 31, a parsing module 32, a second determination module 33, and a decryption module 34. The second acquisition module 31 is used to acquire information about the data user and an encrypted identifier in the target data; wherein the data user has permission to use the target data. The parsing module 32 is used to parse the encrypted identifier to obtain reference information and encrypted information. The second determination module 33 is used to determine a key based on the reference information and the data user's information. The decryption module 34 is used to decrypt the encrypted information using the key to obtain a user identifier corresponding to the encrypted identifier.

[0194] Furthermore, the encrypted identifier includes a first part of information at the front and a second part of information at the back. Correspondingly, when the parsing module 32 parses the encrypted identifier to obtain reference information and encrypted information, it is specifically used for:

[0195] The first part of the information is parsed to obtain the reference information; the second part of the information is the encrypted information to be decrypted.

[0196] Furthermore, the reference information includes: version information and service scenario type; the version information includes at least one of algorithm version information and key version information. Correspondingly, when the second determining module 33 determines the key based on the reference information and the data user's information, it is specifically used for:

[0197] Based on the service scenario type, the service object identifier is determined from the information of the data user; based on the reference information and the service object identifier, the key is determined.

[0198] Furthermore, when the decryption module 34 uses the key to decrypt the encrypted information and obtain the user identifier corresponding to the encrypted identifier, it is specifically used for:

[0199] The encrypted information is decrypted using the key to obtain first encoded information; the first encoded information is parsed to obtain parsed information; if the parsed information contains service object extension information, the user identifier is extracted from the parsed information; if the parsed information does not contain service object extension information, the parsed information is the user identifier.

[0200] Furthermore, the information regarding the data user includes: the tool identifier and user identifier corresponding to the third-party tool developed based on the open platform; wherein, the user identifier is either the developer identifier corresponding to the third-party tool developer or the user identifier corresponding to the third-party tool user. The reference information includes: version information and service scenario type, wherein the version information includes at least one of algorithm version information and key version information. Accordingly,

[0201] When the second determining module 33 determines the service object identifier based on the reference information and the information of the data user, it is specifically used for:

[0202] Based on the service scenario type, at least one identifier is determined from the tool identifier and the user identifier as the service object identifier.

[0203] It should be noted that the decryption device for the user identifier in the data provided in this embodiment can implement the technical solution described in the above embodiment of the decryption method for the user identifier in the data. The specific implementation principle of each module or unit can be found in the corresponding content in the above embodiment of the method, and will not be repeated here.

[0204] This application provides a schematic diagram of the principle structure of a computing device according to an embodiment. The schematic diagram is as follows: Figure 8 As shown. Specifically, the computing device includes a memory 51 and a processor 52. The memory 51 is used to store one or more computer instructions; the processor 52, coupled to the memory 51, is used by the at least one or more computer instructions (such as computer instructions for implementing data storage logic) to implement the steps in the encryption method for user identifiers in data provided in the embodiments of this application, or the steps in the decryption method for user identifiers in data.

[0205] In the above, memory 51 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0206] Figure 8 The diagram only schematically illustrates some of the components that a computing device may contain, and does not imply that the computing device only includes... Figure 8 The components shown include, for example, audio component 56, display 54, power supply component 55, communication component 53, etc.

[0207] Another embodiment of this application provides a computer program product (not shown in the accompanying drawings). This computer program product includes a computer program or instructions that, when executed by a processor, enable the processor to perform the steps described in the above method embodiments.

[0208] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the method steps or functions provided in the above embodiments.

[0209] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0210] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for encrypting user identifiers in data, characterized in that, include: Obtain the target data to be sent to the data user and the information of the data user; wherein, the information of the data user includes a tool identifier and a user identifier; Based on the preset scenario configuration information, reference information is determined; wherein, the reference information includes the service scenario type; When the service scenario type is the first type, the user identifier is determined as the service object identifier; When the service scenario type is the second type, the tool identifier is determined as the service object identifier; The key is determined based on the reference information and the service object identifier; The user identifier in the target data is encrypted using the key to obtain encrypted information; Based on the reference information and the encryption information, an encrypted identifier corresponding to the user identifier is generated; The first type corresponds to a scenario where user data between tools developed by different developers cannot be shared or aggregated, while the second type corresponds to a scenario where user data between different tools cannot be shared or aggregated.

2. The method according to claim 1, characterized in that, The reference information also includes version information; the version information includes at least one of algorithm version information and key version information.

3. The method according to claim 2, characterized in that, The information of the data user includes: the tool identifier and user identifier corresponding to the third-party tool developed based on the open platform; wherein, the user identifier is the developer identifier corresponding to the third-party tool developer or the user identifier corresponding to the third-party tool user.

4. The method according to claim 3, characterized in that, Also includes: If either the tool identifier or the user identifier is determined to be the service object identifier, then the other is the service object extended information; and / or Obtain timestamp information and use the timestamp information as extended information of the service object; and / or The pre-set information is used as extended information for the service object.

5. The method according to claim 4, characterized in that, The user identifier in the target data is encrypted using the key to obtain encrypted information, including: The user identifier and the service object extended information are encoded to obtain first encoded information; The first encoded information is encrypted using the key to obtain the encrypted information.

6. The method according to any one of claims 1 to 5, characterized in that, Determining the key based on the reference information and the service object identifier includes: The reference information and the service object identifier constitute the query keywords; Check if a key associated with the query keywords exists in the local memory; If the key exists in local memory, it can be retrieved. If the key is not present in local memory, check if the key associated with the query keyword is in the Redis cache. If the key is present in the Redis cache, it can be retrieved. If the key is not found in the Redis cache, query the database for the key associated with the query keyword.

7. The method according to any one of claims 1 to 5, characterized in that, Based on the reference information and the encryption information, an encrypted identifier corresponding to the user identifier is generated, including: The reference information is encoded to obtain second encoded information; The second encoded information is placed before the encrypted information to obtain the encrypted identifier corresponding to the user identifier.

8. A method for decrypting user identifiers in data, characterized in that, include: Obtain information about the data user and the encrypted identifier in the target data; wherein the data user has the authority to use the target data; the information about the data user includes a tool identifier and a user identifier; The encrypted identifier is parsed to obtain reference information and encrypted information; wherein, the reference information includes a service scenario type; when the service scenario type is a first type, the user identifier is a service object identifier; when the service scenario type is a second type, the tool identifier is a service object identifier; The key is determined based on the reference information and the service object identifier; The encrypted information is decrypted using the key to obtain the user identifier corresponding to the encrypted identifier; The first type corresponds to a scenario where user data between tools developed by different developers cannot be shared or aggregated, while the second type corresponds to a scenario where user data between different tools cannot be shared or aggregated.

9. The method according to claim 8, characterized in that, The encrypted identifier includes a first part of information at the front and a second part of information at the back; as well as The encrypted identifier is parsed to obtain reference information and encrypted information, including: The reference information is obtained by parsing the first part of the information; The second part of the information is the encrypted information to be decrypted.

10. The method according to claim 8, characterized in that, The reference information also includes version information; the version information includes at least one of algorithm version information and key version information.

11. The method according to any one of claims 8 to 10, characterized in that, Using the key to decrypt the encrypted information, the user identifier corresponding to the encrypted identifier is obtained, including: The encrypted information is decrypted using the key to obtain the first encoded information; The first encoded information is parsed to obtain the parsed information; If the parsed information contains extended service object information, then the user identifier is extracted from the parsed information; If the parsed information does not contain service object extended information, then the parsed information is the user identifier.

12. A data service system, characterized in that, include: The data provider stores the data; The data processing subsystem has an open platform that provides APIs; Data users access the data processing subsystem via the API to obtain data stored at the data provider's location through the data processing subsystem. The data processing subsystem is configured to acquire target data to be sent to a data user and information about the data user; wherein the information about the data user includes a tool identifier and a user identifier; determine reference information based on preset scenario configuration information; the reference information includes a service scenario type; when the service scenario type is a first type, the user identifier is determined as a service object identifier; when the service scenario type is a second type, the tool identifier is determined as a service object identifier; determine a key based on the reference information and the service object identifier; encrypt the user identifier in the target data using the key to obtain encrypted information; and generate an encrypted identifier corresponding to the user identifier based on the reference information and the encrypted information. The first type corresponds to a scenario where user data between tools developed by different developers cannot be shared or aggregated, while the second type corresponds to a scenario where user data between different tools cannot be shared or aggregated.

13. The system according to claim 12, characterized in that, The data user is used to obtain information about the data user and the encrypted identifier in the target data; wherein the data user has the authority to use the target data; the encrypted identifier is parsed to obtain reference information and encrypted information; a key is determined based on the reference information and the service object identifier; the encrypted information is decrypted using the key to obtain the user identifier corresponding to the encrypted identifier.

14. A computing device, characterized in that, include: Memory and processor, among which, The memory stores one or more computer instructions; The processor, coupled to the memory, is configured to execute one or more computer instructions to implement the steps of the method according to any one of claims 1 to 7, or the steps of the method according to any one of claims 8 to 11.

Images