Data communication method and device, medium, electronic equipment and program product

By using identity tokens for authentication during client-server interactions, the consistency of executable files during code integration and runtime is ensured, solving the problems of pre-allocated authentication tokens and key leakage, and improving communication security.

CN122069047APending Publication Date: 2026-05-19TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-19
Publication Date
2026-05-19

AI Technical Summary

Technical Problem

In existing technologies, the pre-allocated and stored authentication identifiers and keys in the interaction and communication between the client and the server are at risk of data leakage, resulting in insufficient communication security.

Method used

By obtaining the identity token of the target process and using the identity token for authentication, the consistency of executable files during code integration and runtime is ensured. The identity file is composed of module name, module signature, timestamp, etc., and is combined with process signature for consistency verification to generate and verify the identity token.

Benefits of technology

It achieves comprehensive authentication across multiple spatial and temporal dimensions, reducing the risk of authentication information leakage and improving the security of data communication.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122069047A_ABST
    Figure CN122069047A_ABST
Patent Text Reader

Abstract

The invention belongs to the technical field of computers and Internet, and particularly relates to a data communication method, a data communication device, a computer readable medium, electronic equipment and a computer program product. The method comprises the steps of obtaining a data communication request initiated by a target process, wherein the target process is used for running a specified function module in an application program; obtaining an identity token obtained by performing identity authentication on the target process, wherein the identity token is used for representing that the specified function module has an executable file with consistent content in a code integration stage and a code operation stage; sending a data communication request carrying the identity token to a communication object; and when the communication object passes verification of the identity token, receiving response data which is returned by the communication object and aims at the data communication request. According to the invention, the data communication security can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of computer and Internet technology, and specifically relates to a data communication method, a data communication device, a computer-readable medium, an electronic device, and a computer program product. Background Technology

[0002] In modern software architectures, communication between clients and servers typically requires authentication of the requesting party to ensure the legitimacy of the communication request and the security of the communication data. For example, authentication identifiers and keys representing the client's identity can be pre-stored in a database. When a client initiates a communication request to the server, it can simultaneously send its authentication identifier and key to the server, which then performs the client authentication.

[0003] However, pre-allocated and stored authentication identifiers and keys are at risk of data leakage. Any requester may forge the request identity by misusing the authentication identifiers and keys, resulting in communication security risks. Summary of the Invention

[0004] This application provides a data communication method, a data communication device, a computer-readable medium, an electronic device, and a computer program product, with the aim of improving data communication security.

[0005] According to one aspect of the embodiments of this application, a data communication method is provided, the method comprising: acquiring a data communication request initiated by a target process, the target process being used to run a specified functional module in an application; acquiring an identity token obtained by authenticating the target process, the identity token being used to indicate that the specified functional module has an executable file with consistent content during the code integration phase and the code execution phase; sending a data communication request carrying the identity token to a communication object; and receiving response data for the data communication request returned by the communication object when the communication object verifies the identity token.

[0006] According to one aspect of the embodiments of this application, a data communication apparatus is provided, the apparatus comprising:

[0007] The first acquisition module is configured to acquire data communication requests initiated by a target process, the target process being used to run a specified functional module in an application.

[0008] The second acquisition module is configured to acquire an identity token obtained by authenticating the target process. The identity token is used to indicate that the specified functional module has an executable file with consistent content during the code integration phase and the code execution phase.

[0009] The sending module is configured to send a data communication request carrying the identity token to the communication object;

[0010] The receiving module is configured to receive response data returned by the communication object in response to the data communication request when the communication object successfully verifies the identity token.

[0011] In some embodiments of this application, based on the above technical solutions, the second acquisition module includes:

[0012] The file acquisition module is configured to acquire the identity file generated by the specified functional module during the code integration phase. The identity file is an encoded file used to identify the specified functional module.

[0013] The signature acquisition module is configured to acquire the process signature generated by the target process during the code execution phase, and the process signature is used to identify the executable file run by the target process;

[0014] The consistency verification module is configured to perform consistency verification on the identity file and the process signature, and generate the identity token of the target process when the verification passes.

[0015] In some embodiments of this application, based on the above technical solutions, the identity file includes a module name and a module signature, wherein the module name is used to uniquely identify the identity of a specified functional module, and the module signature is used to verify the authenticity of the identity file; the file acquisition module includes:

[0016] The executable file acquisition module is configured to acquire a first executable file, which is an executable file generated by the specified functional module during the code integration phase;

[0017] The fingerprint extraction module is configured to extract the fingerprint of the first executable file to obtain the module fingerprint of the specified functional module.

[0018] The string signature module is configured to perform signature processing on a concatenated string including the module name and the module fingerprint to obtain a module signature;

[0019] The encoding module is configured to encode the encoding fields, including the module name and the module signature, to obtain an identity file.

[0020] In some embodiments of this application, based on the above technical solutions, the identity file further includes a timestamp, which is used to represent the generation time of the identity file; the string signature module includes:

[0021] The field combination module is configured to combine the module name, the module fingerprint, and the timestamp into a concatenated string.

[0022] The summary extraction module is configured to perform a hash operation on the concatenated string according to a preset summary algorithm to obtain the summary information of the concatenated string;

[0023] The digest encryption module is configured to encrypt the digest information based on the private key of the token issuer to obtain a module signature. The token issuer is used to issue an identity token to the target process.

[0024] In some embodiments of this application, based on the above technical solutions, the encoding module includes:

[0025] The field replacement module is configured to replace the module fingerprint in the concatenated string with the module signature to obtain an encoded field.

[0026] The field encoding module is configured to encode the encoded field to obtain an identity file.

[0027] In some embodiments of this application, based on the above technical solutions, the field replacement module is further configured to: remove the module fingerprint from the concatenated string; and add the module signature to the end of the concatenated string.

[0028] In some embodiments of this application, based on the above technical solutions, the field encoding module is further configured to: convert each field in the encoded field into a binary byte sequence; decompose the binary byte sequence into sequence blocks of fixed length, and add a continuation bit to the head of each sequence block, the continuation bit being used to indicate whether the sequence block is the first sequence block in the binary byte sequence; arrange the sequence blocks in little-endian order to obtain the encoded value of the field; and sequentially concatenate the identifier of each field with the encoded value to obtain the identity file.

[0029] In some embodiments of this application, based on the above technical solutions, the signature acquisition module is further configured to: acquire a second executable file, wherein the second executable file is an executable file that is run by the target process during the code execution phase; extract a fingerprint from the second executable file to obtain a process fingerprint of the target process; and perform signature processing on the process fingerprint to obtain a process signature.

[0030] In some embodiments of this application, based on the above technical solutions, the signature acquisition module is further configured to: acquire a signature key and a signature algorithm for signing the process fingerprint; divide the signature key into multiple subkeys, the multiple subkeys being used to perform XOR operations with input data in multiple encryption rounds; replace at least one encryption operation in the signature algorithm with a lookup table, the lookup table being used to map the input data to the output data obtained after the encryption operation; and perform multiple rounds of encryption processing on the process fingerprint according to the multiple subkeys and the lookup table to obtain the process signature.

[0031] In some embodiments of this application, based on the above technical solutions, the consistency verification module is further configured to: extract the module name from the identity file; find the module fingerprint corresponding to the module name from the database; perform signature processing on the module fingerprint to obtain the signature to be verified; if the signature to be verified is consistent with the process signature content, then the consistency verification result is determined to be verified as passed.

[0032] In some embodiments of this application, based on the above technical solutions, the consistency verification module is further configured to: decode the identity file to obtain an encoded field, the encoded field including a module signature and a field to be verified; decrypt the module signature according to the public key of the token issuing end to obtain a first string; concatenate the field to be verified with the module fingerprint to obtain a second string; if the content of the first string and the second string is consistent, then generate the identity token of the target process.

[0033] In some embodiments of this application, based on the above technical solutions, the identity token includes a module name, an expiration time, and a token signature. The module name is used to uniquely identify the identity of a specified functional module, the expiration time is used to indicate the validity period of the identity token, and the token signature is used to verify the authenticity of the identity token. The method for generating the identity token includes: concatenating the module name and the expiration time into a string; performing a hash operation on the concatenated string according to a preset digest algorithm to obtain digest information of the concatenated string; encrypting the digest information according to the private key of the token issuing end to obtain a token signature; adding the token signature to the end of the concatenated string; and encoding the concatenated string to obtain the identity token.

[0034] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the data communication method as described in the above technical solutions.

[0035] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the executable instructions to implement the data communication method as described in the above technical solutions.

[0036] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the data communication method as described in the above technical solutions.

[0037] In the technical solution provided in this application embodiment, by authenticating the target process and obtaining its identity token, a data communication request carrying the identity token can be sent to the communication object. When the communication object successfully verifies the identity token, a response data for the communication request is received from the communication object. This application embodiment extends the subject of identity authentication in communication interaction from the top-level application layer to the bottom-level designated functional module used to implement a certain application function, and extends it from static functional code to dynamically running processes. The content of identity authentication is integrated throughout the code integration and execution phases of the designated functional module. Therefore, it can achieve comprehensive authentication across multiple spatial levels and multiple time dimensions, thereby reducing the risk of authentication information leakage and improving data communication security.

[0038] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0040] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0041] Figure 2 A flowchart of a data communication method according to one embodiment of this application is shown.

[0042] Figure 3 A flowchart illustrating the authentication of a target process in one embodiment of this application is shown.

[0043] Figure 4 A flowchart of an identity file generation method in one embodiment of this application is shown.

[0044] Figure 5 This illustration shows an application scenario diagram of generating an identity file during the code integration stage, according to an embodiment of this application.

[0045] Figure 6 A flowchart of a process signature generation method in one embodiment of this application is shown.

[0046] Figure 7 A flowchart illustrating the consistency verification of identity files and process signatures in one embodiment of this application is shown.

[0047] Figure 8 This illustration shows an application scenario of interactive communication based on process identity authentication during the code execution phase, according to an embodiment of this application.

[0048] Figure 9 A schematic block diagram of the data communication device provided in an embodiment of this application is shown.

[0049] Figure 10 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0050] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0051] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0052] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0053] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0054] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0055] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0056] like Figure 1 As shown, the system architecture 100 may include terminal devices 110, a network 120, and a server 130. Terminal devices 110 may include various electronic devices such as smartphones, tablets, laptops, desktop computers, smart speakers, smart wearable devices, smart in-vehicle devices, and smart payment terminals. Server 130 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal devices 110 and server 130, such as a wired communication link or a wireless communication link.

[0057] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices, networks, and servers. For example, server 130 can be a server group composed of multiple server devices. In addition, the technical solutions provided in this application embodiment can be applied to terminal device 110, or to server 130, or can be implemented jointly by terminal device 110 and server 130. This application does not impose any special limitations on this.

[0058] For example, various types of applications can run on terminal device 110. For instance, local applications can be run by installing a client, web applications can be run by accessing a specified Uniform Resource Identifier (URI) through a browser, and hosted applications that do not require client installation can be run using a host program installed locally.

[0059] Applications running on terminal device 110 can communicate and interact with server 130 via network 120. For example, they can download resources stored on server 130 to local storage or upload local data to the server for storage.

[0060] When an application running on terminal device 110 initiates a communication request to server 130, authentication can be performed on the target process initiating the request to obtain an identity token for that target process. The target process is used to run a specified functional module within the application, and the identity token indicates that the specified functional module has an executable file with consistent content during both the code integration and execution phases.

[0061] Terminal device 110 sends a communication request carrying an identity token to server 130, which then verifies the identity token. If server 130 verifies the identity token successfully, it can return response data to terminal device 110 for the communication request, enabling network communication for the target process. If server 130 fails to verify the identity token, it can refuse to respond to the communication request initiated by terminal device 110. This ensures that only trusted target processes can interact and communicate, thus improving the communication security of the application.

[0062] The following detailed description, in conjunction with specific embodiments, outlines the technical solutions provided in this application, including data communication methods, data communication devices, computer-readable media, electronic devices, and computer program products.

[0063] Figure 2 A flowchart of a data communication method according to one embodiment of this application is shown. This data communication method can be... Figure 1 The method can be executed by the terminal device or server shown, or it can be executed jointly by the terminal device and the server. This application uses a data communication method executed on a terminal device as an example for illustration. For example... Figure 2 As shown, the data communication method may include the following steps S210 to S240.

[0064] S210: Obtain a data communication request initiated by the target process, which is used to run a specified functional module in the application.

[0065] S220: Obtain the identity token obtained by authenticating the target process. The identity token is used to indicate that the specified functional module has an executable file with consistent content during the code integration phase and the code execution phase.

[0066] S230: Send a data communication request carrying an identity token to the communication object.

[0067] S240: When the communication object successfully verifies the identity token, receive the response data returned by the communication object in response to the data communication request.

[0068] An application is a software program that provides specific functions or services to a user. Applications can be desktop software, mobile applications, web applications, or server-side software. They typically consist of multiple functional modules, each responsible for implementing different application functions. Applications can be single-threaded or multi-threaded, depending on their design and functional requirements.

[0069] A process is an instance of a running program in an operating system. Each process has its own memory space, system resources, and execution environment. The process is the basic unit for resource allocation and scheduling by the operating system. A process can contain one or more threads, and a thread is an execution flow within a process.

[0070] When a user launches an application, the operating system creates a new process to run that application. This process contains all the application's code, data, and resources. For example, when a user opens a web browser, the operating system creates a new process to run the browser application. Some complex applications may require multiple processes to perform their functions. These processes can be independent or collaborative. For example, a large server application may need to create multiple processes to handle different tasks, such as database operations and network communication.

[0071] It should be noted that the target process in the embodiments of this application should be interpreted broadly. It may include the main process that runs the application on the terminal device, as well as single-level or multi-level child processes created by the main process, and may also include threads that execute in the process.

[0072] From development to installation and use, an application typically goes through three key stages: code integration, code delivery, and code execution. Each stage has its specific goals and processes.

[0073] The goal of the code integration phase is to merge the code of different functional modules developed by multiple developers into a shared codebase, ensuring code compatibility and consistency. The goal of the code delivery phase is to deploy the integrated code to a production or pre-production environment, ensuring code stability and reliability. The goal of the code execution phase is to ensure the code runs stably in the production environment and that code performance can be continuously monitored and optimized.

[0074] In one embodiment of this application, continuous integration (CI) and continuous delivery (CD) can be used to implement application development and deployment.

[0075] Continuous integration refers to developers frequently integrating code into the main branch. Each integration is verified through automated builds (including compilation, deployment, and automated testing) to detect integration errors as early as possible.

[0076] Continuous delivery, building upon continuous integration, automatically deploys code to pre-production or production environments. Continuous delivery ensures the rapid and secure delivery of new versions of code to quality assurance teams or users, facilitating subsequent production deployments. Continuous delivery means that all changes, including new features, configuration changes, bug fixes, and experiments, are delivered to users as quickly as possible without posing any risk to the business.

[0077] In the data communication method provided in this application embodiment, the subject of identity authentication in communication interaction is extended from the top-level application level to the bottom-level designated functional module used to implement a certain application function, and from static functional code to dynamically running process. The content of identity authentication runs through the code integration stage and code execution stage of the designated functional module. Therefore, it can achieve comprehensive authentication across multiple spatial levels and multiple time dimensions, thereby reducing the risk of authentication information leakage and improving the communication security of the application.

[0078] Figure 3 A flowchart illustrating the authentication of a target process in one embodiment of this application is shown. Figure 3 As shown, based on the above embodiments, the method for authenticating the target process may include the following steps S310 to S330.

[0079] S310: Obtain the identity file generated by the specified functional module during the code integration phase. The identity file is an encoded file used to identify the specified functional module.

[0080] S320: Obtain the process signature generated by the target process during the code execution phase. The process signature is used to identify the executable file run by the target process.

[0081] S330: Perform consistency verification on the identity file and process signature, and generate the identity token of the target process when the verification passes.

[0082] The following describes in detail the specific implementation of each step in this identity authentication method using multiple embodiments.

[0083] In step S310, the identity file generated by the specified functional module during the code integration phase is obtained. The identity file is an encoded file used to identify the specified functional module.

[0084] In one embodiment of this application, the identity file includes the following encoded fields:

[0085] The module name is used to uniquely identify a specific functional module.

[0086] Module signature, a digital signature generated based on the token issuer's private key, is used to verify the authenticity of identity documents.

[0087] This application's embodiments effectively ensure the uniqueness and authenticity of functional modules by introducing two coded fields: module name and module signature. The module name serves as a unique identifier, facilitating the management and identification of each module; while the module signature uses a digital signature generated from the private key during code integration to verify the identity file, thereby preventing identity forgery and tampering during subsequent code interaction and execution, enhancing system security. This application's embodiments contribute to building a reliable and trustworthy software environment, particularly in complex applications involving multi-module collaboration and integration, effectively improving overall security and trustworthiness.

[0088] In one embodiment of this application, the identity file further includes the following encoded fields:

[0089] A timestamp is used to indicate when the identity file was generated.

[0090] This application's embodiments, by adding a timestamp field to the identity file, provide a precise time record of the identity file's generation. This not only helps track and audit the creation and usage history of the identity file but also plays a crucial role in verifying its timeliness and integrity. The introduction of timestamps enhances the traceability of the identity file, enabling rapid identification of problems and appropriate measures to be taken in the event of a security incident or when compliance checks are required, thereby improving the security and reliability of the application.

[0091] Figure 4 A flowchart illustrating a method for generating an identity file in one embodiment of this application is shown. Figure 4 As shown, based on the above embodiments, step S310 may further include the following steps S311 to S314.

[0092] S311: Obtain the first executable file, which is the executable file generated by the specified functional module during the code integration phase.

[0093] The executable file generated during the code integration phase of a functional module refers to the binary file that can be directly run on the target system after the module's source code has undergone multiple key steps such as compilation, assembly, and linking. Compilation converts the module's source code (such as code written in languages ​​like C, C++, and Java) into object code (usually assembly language); assembly converts the object code into machine code, i.e., binary instructions; and linking combines the module's binary instructions with other dependent library files or modules to form a complete executable file.

[0094] During the code integration phase, the executable files of multiple functional modules are integrated together to form a complete application or service. This process typically involves practices such as version control, code review, automated testing, and continuous integration to ensure the quality and stability of the integrated code.

[0095] S312: Extract the fingerprint of the first executable file to obtain the module fingerprint of the specified functional module.

[0096] Module fingerprints can be used to verify the integrity and authenticity of a first executable file. Methods for extracting fingerprints from the first executable file can include hash algorithms and derived algorithms such as Simhash, Minhash, and Winnowing.

[0097] The hash algorithm uses hash functions such as SHA-256 and MD5 to perform hash calculations on the first executable file, generating a fixed-length hash value. This hash value can be regarded as a digital fingerprint of the file content, and even a small change will cause a significant change in the hash value.

[0098] The Simhash algorithm is based on Locality Sensitive Hashing (LSH). Unlike MD5 and SHA hash algorithms, LSH can calculate similar hash values ​​for similar strings. The Simhash algorithm calculates the hash value of each characteristic keyword in the executable file and then merges them to obtain the module fingerprint.

[0099] Minhash is also an LSH algorithm and a dimensionality reduction method. The basic idea of ​​the Minhash algorithm is to use a set of random hash functions to perform hash operations on each element in the executable file, obtain the minimum hash value, and form a module fingerprint based on the minimum hash value matrix.

[0100] The Winnowing algorithm selects a fixed-size sliding window from all generated file fingerprint sequences, choosing the smallest hash value within each window. If multiple minimum values ​​exist, the rightmost one is selected. This strategy ensures that a sufficient amount of fingerprint information is selected while preventing the generation of excessively large fingerprints.

[0101] S313: Perform signature processing on the concatenated string including the module name and module fingerprint to obtain the module signature.

[0102] In one embodiment of this application, the method for signing a concatenated string may include: assembling a concatenated string from a module name, a module fingerprint, and a timestamp; performing a hash operation on the concatenated string according to a preset digest algorithm to obtain a digest of the concatenated string; and encrypting the digest information according to the private key of the token issuer to obtain a module signature, wherein the token issuer is used to issue an identity token to the target process.

[0103] This application embodiment effectively enhances the security and verifiability of identity tokens by hashing a concatenated string consisting of the module name, module fingerprint, and timestamp, and then encrypting it with a private key. This not only ensures the identity authentication and data integrity of the token issuer but also increases the token's timeliness through the timestamp, making any unauthorized modifications easily detectable, thereby improving the overall security and reliability of the identity file.

[0104] In one embodiment of this application, the fields used for signature processing are shown in Table 1 below.

[0105] Table 1

[0106]

[0107] The multiple signature fields shown in Table 1 are concatenated using a specified delimiter to obtain the concatenated string S. For example, the concatenated string S can be represented as:

[0108] S=version|moduleName|exeHash|timestamp

[0109] By using a digital signature algorithm (such as SHA256withRsa) to sign the concatenated string S with the private key of the token issuer, the module signature (signature) can be obtained.

[0110] A digital signature is a technology used to verify the integrity of digital information and the identity of the sender. Based on public-key cryptography, it ensures that information has not been tampered with during transmission and confirms the sender's identity. The working principle of a digital signature includes: the sender encrypts the message using their private key, generating a digital signature. The sender attaches this digital signature to the message and then sends both the message and the digital signature to the recipient. Upon receiving the message and the digital signature, the recipient decrypts the digital signature using the sender's public key. The decrypted content is compared with the received message; if they match, it proves that the message has not been tampered with during transmission and that it indeed came from the claimed sender.

[0111] SHA256 is a Secure Hash Algorithm 2 (SHA) algorithm, where 256 represents the number of bits in the generated hash value. SHA256 is a cryptographic hash function that generates a unique hash value of fixed length (256 bits) regardless of the size of the input data. SHA256 is commonly used in various cryptographic applications, including digital signatures and certificate fingerprint generation.

[0112] S314: Encode the encoded fields, including the module name and module signature, to obtain the identity file.

[0113] In one embodiment of this application, the method for encoding the encoded field may include: replacing the module fingerprint in the concatenated string with the module signature to obtain the encoded field; and encoding the encoded field to obtain the identity file.

[0114] This application embodiment replaces the module fingerprint with the module signature, which on the one hand can hide the module fingerprint and prevent it from being directly exposed in the system, and on the other hand can use the module signature to form a trusted authentication for the concatenated string containing the module fingerprint, thus ensuring the verifiability of the identity file without exposing the module fingerprint.

[0115] In one embodiment of this application, replacing the module fingerprint in the concatenated string with the module signature includes: removing the module fingerprint from the concatenated string; and adding the module signature to the end of the concatenated string.

[0116] In this embodiment, the module signature is attached to the end of the concatenated string, which can improve the authentication efficiency of identity files. That is, in the identity authentication process, only the module signature located at the end needs to be decoded and verified to quickly complete the identity authentication.

[0117] In one embodiment of this application, the method for encoding the encoded field may further include: converting each field in the encoded field into a binary byte sequence; decomposing the binary byte sequence into sequence blocks of fixed length, and adding a continuation bit to the head of each sequence block, the continuation bit being used to indicate whether the sequence block is the first sequence block in the binary byte sequence; arranging the sequence blocks in little-endian order to obtain the encoded value of the field; and concatenating the identifier of each field with the encoded value in sequence to obtain the identity file.

[0118] For example, the encoded field includes multiple fields such as protocol version, module name, timestamp and module signature arranged in sequence. Each field is converted into a binary byte sequence, and then the binary byte sequence is decomposed in order from the least significant bit to the most significant bit to obtain a sequence block of length 7. When the length is insufficient, 0 can be padded in the most significant bit.

[0119] For example, if a binary byte sequence is 100101100, 7 bytes are extracted sequentially from the least significant bit to the most significant bit to obtain the first sequence block 0101100; the remaining 2 bytes are extracted and padded with 0s in the most significant bit to obtain the second sequence block 0000010.

[0120] Then, a continuation bit is added to the header of each sequence block. A continuation bit value of 1 indicates that the current sequence block is not the first sequence block in the binary byte sequence; a continuation bit value of 0 indicates that the current sequence block is the first sequence block in the binary byte sequence.

[0121] For example, for the first sequence block 0101100 extracted from the end of the binary byte sequence, a continuation bit with a value of 1 can be added to its head; while for the second sequence block 0000010 located at the head of the binary byte sequence, a continuation bit with a value of 0 can be added to its head.

[0122] Finally, the sequence blocks are arranged in little-endian order and combined to obtain the encoded value of the corresponding field. For example, the first sequence block 10101100 with the continuation bit added is placed at the beginning, and the second sequence block 00000010 with the continuation bit added is placed at the end, and the combined result is the encoded value of the current field as 1010110000000010.

[0123] After obtaining the encoded value of each field, the fields are concatenated sequentially in the order of identifier + encoded value to obtain the complete identity file. The identifier is used to identify the field type corresponding to each encoded value.

[0124] In one embodiment of this application, the data serialization protocol Protocol Buffers can be used to serialize and encode the encoded fields to form an identity file.

[0125] In one embodiment of this application, the encoding field used for encoding processing can be represented as version|moduleName|timestamp|signature, for example.

[0126] Unlike traditional digital signature algorithms, the encoding field in this application embodiment does not include module fingerprints, thereby improving the security of identity authentication.

[0127] Figure 5 This illustration shows an application scenario diagram of generating an identity file during the code integration phase, according to an embodiment of this application. The security center represents the token issuing end used to provide identity authentication services to the target process.

[0128] like Figure 5 As shown, after the specified functional module submits its source code, it can trigger continuous integration compilation to generate the first executable file (exe). Then, the module fingerprint is extracted using the SHA256 algorithm and recorded in the security center.

[0129] The security center uses a private key to sign the module fingerprint, obtaining the corresponding module signature. It then further encodes the fields including the module name and module signature to obtain the identity file.

[0130] At the same time, the security center can establish a mapping relationship between module names and module signatures and save it in the database.

[0131] After obtaining the identity file, the first executable file and the identity file can be deployed together on electronic devices serving as pre-production or production environments during the continuous delivery phase of the code.

[0132] Figure 6 A flowchart illustrating a method for generating a process signature in one embodiment of this application is shown. Figure 6 As shown, based on the above embodiments, step S320 may further include the following steps S321 to S323.

[0133] Obtain the process signature generated by the target process during the code execution phase, including:

[0134] S321: Obtain a second executable file, which is an executable file that the target process runs during the code execution phase.

[0135] During the code execution phase, the second executable file corresponding to the target process can be found in the virtual file system / proc directory based on the target process's process identifier (PID).

[0136] The / proc directory provides information about system hardware, running processes, and the current state of the system. The files in the / proc directory are not actually stored on the disk; rather, they are dynamically generated by the kernel to provide an interface for system information.

[0137] A Process ID (PID) is used to identify and distinguish running processes in the operating system. Each process is assigned a unique PID upon creation, and this PID is unique throughout the entire system and will not be reused by other processes immediately after the process terminates.

[0138] S322: Extract the fingerprint of the second executable file to obtain the process fingerprint of the target process.

[0139] The method for fingerprint extraction of the second executable file is the same as the method for fingerprint extraction of the first executable file. For details, please refer to the above embodiment, which will not be repeated here.

[0140] S323: Perform signature processing on the process fingerprint to obtain the process signature.

[0141] In one embodiment of this application, a method for signing a process fingerprint may include: obtaining a signature key and a signature algorithm for signing the process fingerprint; dividing the signature key into multiple subkeys, the multiple subkeys being used to perform XOR operations with input data in multiple encryption rounds; replacing at least one encryption operation in the signature algorithm with a lookup table, the lookup table being used to map the input data to the output data obtained after the encryption operation; and performing multiple rounds of encryption processing on the process fingerprint according to the multiple subkeys and the lookup table to obtain a process signature.

[0142] This application employs key splitting and lookup table replacement, using multiple rounds of encryption to hide the signature key and algorithm within the signature result. This ensures the integrity and security of the signing process while maintaining transparency. Even if the second executable file is decompiled after the signature processing, the signature remains valid.

[0143] Figure 7 A flowchart illustrating a consistency verification process for an identity file and process signature is shown in one embodiment of this application. The consistency verification method can be... Figure 5 The security center shown is in operation.

[0144] like Figure 7 As shown, based on the above embodiments, step S330 may further include the following steps S331 to S334.

[0145] S331: Extract the module name from the identity file;

[0146] S332: Retrieve the module fingerprint corresponding to the module name from the database;

[0147] S333: Perform signature processing on the module fingerprint to obtain the signature to be verified;

[0148] S334: If the signature to be verified is consistent with the process signature, then the result of the consistency verification is determined to be that the verification passed.

[0149] This application embodiment, based on the module name extracted from the identity file, can retrieve the module fingerprint corresponding to the module name from the database according to the mapping relationship between module name and module fingerprint. Then, using the same signature algorithm as the process signature, the retrieved module fingerprint is signed to obtain the signature to be verified. If the executable file has not been tampered with during the code integration and execution phases, the first executable file and the second executable file should have the same code content, and the corresponding signature to be verified should also be consistent with the process signature. Therefore, the consistency verification result can be determined as verification passed. Conversely, if the content of the signature to be verified is inconsistent with the process signature, the consistency verification result can be determined as verification failed.

[0150] In one embodiment of this application, if the consistency check result is successful, the security center can generate an identity token for the target process.

[0151] In one embodiment of this application, before generating an identity token for the target process, the identity file can be signed and verified to further improve the security of identity token issuance. The signature verification method may include: decoding the identity file to obtain an encoded field, the encoded field including a module signature and a field to be verified; decrypting the module signature using the public key of the token issuer to obtain a first string; concatenating the field to be verified with the module fingerprint to obtain a second string; and generating an identity token for the target process if the first string and the second string are identical.

[0152] In one embodiment of this application, the identity token generated by the security center may include the following fields:

[0153] The module name is used to uniquely identify a specific functional module.

[0154] Expiration time indicates the validity period of the identity token.

[0155] This application's embodiments effectively enhance the security and flexibility of interactive communication by including two key fields—module name and expiration time—in the identity token. The module name ensures the token's uniqueness, allowing each target process to be accurately identified, thereby preventing token abuse and misuse. The expiration time sets a clear time limit for the token's validity, reducing the risk of prolonged unauthorized use and facilitating token management and updates by the security center, thus improving the overall system security and maintenance efficiency.

[0156] In one embodiment of this application, the identity token further includes the following fields:

[0157] Token signing, a digital signature generated from the private key of the token issuer, is used to verify the authenticity of an identity token.

[0158] By adding a token signature field to the identity token, the system's security is significantly enhanced. The token signature is a digital signature generated using the token issuer's private key, a mechanism that ensures the authenticity of the identity token. When the token is verified by the recipient during transmission, the signature generated by the private key can be used to confirm that the token has not been tampered with and indeed comes from a trusted issuing source. This verification process not only prevents token forgery and tampering but also protects the system from man-in-the-middle attacks, thereby greatly improving the overall security and trustworthiness of the system.

[0159] In one embodiment of this application, the method for generating an identity token may include: concatenating a module name and an expiration time into a string; performing a hash operation on the concatenated string according to a preset digest algorithm to obtain a digest of the concatenated string; encrypting the digest of the digest according to the private key of the token issuer to obtain a token signature; adding the token signature to the end of the concatenated string; and encoding the concatenated string to obtain an identity token.

[0160] The digest algorithm, encryption algorithm, and encoding algorithm used to generate the identity token can be referred to in the description of the relevant algorithms in the above embodiments, and will not be repeated here.

[0161] Figure 8 This illustration shows an application scenario of interactive communication based on process identity authentication during the code execution phase, according to an embodiment of this application.

[0162] like Figure 8 As shown, the target process can obtain its own process ID (PID) through the security SDK, find the corresponding executable file (.exe) in the linux proc directory, calculate the process fingerprint using the sha256 algorithm, and obtain the fingerprint signature whiteBoxSign after signing the process fingerprint.

[0163] The security SDK can send an authentication request to the security center carrying identity documents and a fingerprint signature (whiteBoxSign).

[0164] The security center extracts the module identity from the identity file and queries the database to obtain the module's exeHash;

[0165] Verify that the fingerprint signature sent by the security SDK is consistent;

[0166] Based on the fields version|moduleName|timestamp|signature obtained from the identity file, the original signature string version|moduleName|exeHash|timestamp is regenerated; the signature is verified using the public key of the security center. If the signature is correct, the moduleName is obtained as the trusted module identity.

[0167] A token is generated using a private key to represent the module's identity. Subsequent business operations can use this token to access servers that require authentication. The token protocol is shown in Table 2 below.

[0168] Table 2

[0169] field name English name illustrate Protocol version version Protocol version number, used for protocol upgrades tokenID id unique identifier for token Module Name moduleName Represents the identity of the business module Expiration time expiration time Used to control token expiration. sign signature Sign all fields

[0170] The signature fields are concatenated and separated by a vertical bar (|) to obtain the string S (S = version|id|moduleName|expireTime). Then, the string S is signed with the private key to obtain the signature field. The token can be encoded using protobuf to reduce the data size. After the server verifies the token signature using the public key, it obtains the process identity.

[0171] The server verifies the token signature using the public key and confirms that it is correct and has not expired. It then retrieves the module name from the token to obtain the trusted module identity.

[0172] Before the token expires, the business needs to call the security center to re-authenticate and obtain a new token.

[0173] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0174] The following describes an embodiment of the apparatus of this application, which can be used to execute the data communication method described in the above embodiments of this application. Figure 9 A schematic block diagram of a data communication device provided in an embodiment of this application is shown. Figure 9 As shown, the data communication device 900 includes:

[0175] The first acquisition module 910 is configured to acquire a data communication request initiated by a target process, the target process being used to run a specified functional module in an application.

[0176] The second acquisition module 920 is configured to acquire an identity token obtained by authenticating the target process, the identity token being used to indicate that the specified functional module has an executable file with consistent content in the code integration phase and the code execution phase;

[0177] Sending module 930 is configured to send a communication request carrying the identity token to the communication object;

[0178] The receiving module 940 is configured to receive response data returned by the communication object in response to the communication request when the communication object successfully verifies the identity token.

[0179] In some embodiments of this application, based on the above technical solutions, the second acquisition module 920 includes:

[0180] The file acquisition module is configured to acquire the identity file generated by the specified functional module during the code integration phase. The identity file is an encoded file used to identify the specified functional module.

[0181] The signature acquisition module is configured to acquire the process signature generated by the target process during the code execution phase, and the process signature is used to identify the executable file run by the target process;

[0182] The consistency verification module is configured to perform consistency verification on the identity file and the process signature, and generate the identity token of the target process when the verification passes.

[0183] In some embodiments of this application, based on the above technical solutions, the identity file includes a module name and a module signature, wherein the module name is used to uniquely identify the identity of a specified functional module, and the module signature is used to verify the authenticity of the identity file; the file acquisition module includes:

[0184] The executable file acquisition module is configured to acquire a first executable file, which is an executable file generated by the specified functional module during the code integration phase;

[0185] The fingerprint extraction module is configured to extract the fingerprint of the first executable file to obtain the module fingerprint of the specified functional module.

[0186] The string signature module is configured to perform signature processing on a concatenated string including the module name and the module fingerprint to obtain a module signature;

[0187] The encoding module is configured to encode the encoding fields, including the module name and the module signature, to obtain an identity file.

[0188] In some embodiments of this application, based on the above technical solutions, the identity file further includes a timestamp, which is used to represent the generation time of the identity file; the string signature module includes:

[0189] The field combination module is configured to combine the module name, the module fingerprint, and the timestamp into a concatenated string.

[0190] The summary extraction module is configured to perform a hash operation on the concatenated string according to a preset summary algorithm to obtain the summary information of the concatenated string;

[0191] The digest encryption module is configured to encrypt the digest information based on the private key of the token issuer to obtain a module signature. The token issuer is used to issue an identity token to the target process.

[0192] In some embodiments of this application, based on the above technical solutions, the encoding module includes:

[0193] The field replacement module is configured to replace the module fingerprint in the concatenated string with the module signature to obtain an encoded field.

[0194] The field encoding module is configured to encode the encoded field to obtain an identity file.

[0195] In some embodiments of this application, based on the above technical solutions, the field replacement module is further configured to: remove the module fingerprint from the concatenated string; and add the module signature to the end of the concatenated string.

[0196] In some embodiments of this application, based on the above technical solutions, the field encoding module is further configured to: convert each field in the encoded field into a binary byte sequence; decompose the binary byte sequence into sequence blocks of fixed length, and add a continuation bit to the head of each sequence block, the continuation bit being used to indicate whether the sequence block is the first sequence block in the binary byte sequence; arrange the sequence blocks in little-endian order to obtain the encoded value of the field; and sequentially concatenate the identifier of each field with the encoded value to obtain the identity file.

[0197] In some embodiments of this application, based on the above technical solutions, the signature acquisition module is further configured to: acquire a second executable file, wherein the second executable file is an executable file that is run by the target process during the code execution phase; extract a fingerprint from the second executable file to obtain a process fingerprint of the target process; and perform signature processing on the process fingerprint to obtain a process signature.

[0198] In some embodiments of this application, based on the above technical solutions, the signature acquisition module is further configured to: acquire a signature key and a signature algorithm for signing the process fingerprint; divide the signature key into multiple subkeys, the multiple subkeys being used to perform XOR operations with input data in multiple encryption rounds; replace at least one encryption operation in the signature algorithm with a lookup table, the lookup table being used to map the input data to the output data obtained after the encryption operation; and perform multiple rounds of encryption processing on the process fingerprint according to the multiple subkeys and the lookup table to obtain the process signature.

[0199] In some embodiments of this application, based on the above technical solutions, the consistency verification module is further configured to: extract the module name from the identity file; find the module fingerprint corresponding to the module name from the database; perform signature processing on the module fingerprint to obtain the signature to be verified; if the signature to be verified is consistent with the process signature content, then the consistency verification result is determined to be verified as passed.

[0200] In some embodiments of this application, based on the above technical solutions, the consistency verification module is further configured to: decode the identity file to obtain an encoded field, the encoded field including a module signature and a field to be verified; decrypt the module signature according to the public key of the token issuing end to obtain a first string; concatenate the field to be verified with the module fingerprint to obtain a second string; if the content of the first string and the second string is consistent, then generate the identity token of the target process.

[0201] In some embodiments of this application, based on the above technical solutions, the identity token includes a module name, an expiration time, and a token signature. The module name is used to uniquely identify the identity of a specified functional module, the expiration time is used to indicate the validity period of the identity token, and the token signature is used to verify the authenticity of the identity token. The method for generating the identity token includes: concatenating the module name and the expiration time into a string; performing a hash operation on the concatenated string according to a preset digest algorithm to obtain digest information of the concatenated string; encrypting the digest information according to the private key of the token issuing end to obtain a token signature; adding the token signature to the end of the concatenated string; and encoding the concatenated string to obtain the identity token.

[0202] The specific details of the data communication devices provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0203] Figure 10 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0204] It should be noted that, Figure 10 The computer system 1000 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0205] like Figure 10 As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage section 1008 into random access memory (RAM). The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output interface 1005 (I / O interface) is also connected to the bus 1004.

[0206] The following components are connected to the input / output interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a local area network card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the input / output interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1010 as needed so that computer programs read from it can be installed into the storage section 1008 as needed.

[0207] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit 1001, it performs various functions defined in the system of this application.

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

[0209] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0210] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0211] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0212] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0213] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data communication method, characterized in that, The method includes: Obtain a data communication request initiated by a target process, wherein the target process is used to run a specified functional module in an application; Obtain an identity token obtained by authenticating the target process. The identity token is used to indicate that the specified functional module has an executable file with consistent content during the code integration phase and the code execution phase. Send a data communication request carrying the identity token to the communication object; When the communication object successfully verifies the identity token, it receives response data returned by the communication object in response to the data communication request.

2. The data communication method according to claim 1, characterized in that, Obtaining the identity token obtained by authenticating the target process includes: Obtain the identity file generated by the specified functional module during the code integration phase. The identity file is an encoded file used to identify the specified functional module. Obtain the process signature generated by the target process during the code execution phase; the process signature is used to identify the executable file run by the target process. The identity file and the process signature are verified for consistency, and an identity token for the target process is generated when the verification passes.

3. The data communication method according to claim 2, characterized in that, The identity file includes a module name and a module signature. The module name is used to uniquely identify the identity of a specified functional module, and the module signature is used to verify the authenticity of the identity file. Obtain the identity file generated by the specified functional module during the code integration phase, including: Obtain the first executable file, which is the executable file generated by the specified functional module during the code integration phase; Fingerprint extraction is performed on the first executable file to obtain the module fingerprint of the specified functional module; The concatenated string including the module name and the module fingerprint is signed to obtain the module signature; The encoding fields, including the module name and the module signature, are encoded to obtain the identity file.

4. The data communication method according to claim 3, characterized in that, The identity file also includes a timestamp, which indicates the generation time of the identity file; the signature processing of the concatenated string including the module name and the module fingerprint includes: The module name, the module fingerprint, and the timestamp are combined into a concatenated string; The concatenated string is hashed according to a preset hash algorithm to obtain the hash information of the concatenated string; The digest information is encrypted using the private key of the token issuer to obtain the module signature. The token issuer is used to issue an identity token to the target process.

5. The data communication method according to claim 4, characterized in that, Encoding the encoded fields, including the module name and the module signature, includes: Replace the module fingerprint in the concatenated string with the module signature to obtain the encoded field; The encoded field is encoded to obtain the identity file.

6. The data communication method according to claim 5, characterized in that, Replacing the module fingerprint in the concatenated string with the module signature includes: Remove the module fingerprint from the concatenated string; The module signature is added to the end of the concatenated string.

7. The data communication method according to claim 5, characterized in that, Encoding the encoded field includes: Each field in the encoded field is converted into a binary byte sequence; The binary byte sequence is decomposed into sequence blocks of fixed length, and a continuation bit is added to the head of each sequence block. The continuation bit is used to indicate whether the sequence block is the first sequence block in the binary byte sequence. The sequence blocks are arranged in little-endian order to obtain the encoded value of the field; The identifiers of each field are concatenated with the encoded values ​​in sequence to obtain the identity file.

8. The data communication method according to claim 2, characterized in that, Obtaining the process signature generated by the target process during the code execution phase includes: Obtain a second executable file, which is an executable file that is run by the target process during the code execution phase; Fingerprint extraction is performed on the second executable file to obtain the process fingerprint of the target process; The process fingerprint is signed to obtain the process signature.

9. The data communication method according to claim 8, characterized in that, Signing the process fingerprint includes: Obtain the signature key and signature algorithm used to sign the process fingerprint; The signature key is divided into multiple subkeys, which are used to perform XOR operations with the input data in multiple encryption rounds; Replace at least one encryption operation in the signature algorithm with a lookup table, which is used to map input data to output data obtained after the encryption operation; The process fingerprint is encrypted multiple times using the multiple subkeys and the lookup table to obtain the process signature.

10. The data communication method according to claim 2, characterized in that, Performing a consistency check on the identity file and the process signature includes: Extract the module name from the identity file; The module fingerprint corresponding to the module name is retrieved from the database; The module fingerprint is processed to obtain the signature to be verified; If the signature to be verified is consistent with the process signature, then the result of the consistency verification is determined to be successful.

11. The data communication method according to claim 10, characterized in that, Before generating the identity token for the target process, the method further includes: The identity file is decoded to obtain an encoded field, which includes a module signature and a field to be verified. The module signature is decrypted using the public key of the token issuer to obtain the first string; The field to be verified is concatenated with the module fingerprint to obtain the second string; If the first string and the second string are identical, then an identity token for the target process is generated.

12. The data communication method according to any one of claims 1 to 10, characterized in that, The identity token includes a module name, an expiration time, and a token signature. The module name is used to uniquely identify the identity of a specified functional module. The expiration time is used to indicate the validity period of the identity token. The token signature is used to verify the authenticity of the identity token. The method for generating the identity token includes: Combine the module name and the expiration time into a concatenated string; The concatenated string is hashed according to a preset hash algorithm to obtain the hash information of the concatenated string; The digest information is encrypted using the private key of the token issuer to obtain the token signature; Add the token signature to the end of the concatenated string; The concatenated string is encoded to obtain the identity token.

13. A data communication device, characterized in that, The device includes: The first acquisition module is configured to acquire data communication requests initiated by a target process, the target process being used to run a specified functional module in an application. The second acquisition module is configured to acquire an identity token obtained by authenticating the target process. The identity token is used to indicate that the specified functional module has an executable file with consistent content during the code integration phase and the code execution phase. The sending module is configured to send a data communication request carrying the identity token to the communication object; The receiving module is configured to receive response data returned by the communication object in response to the data communication request when the communication object successfully verifies the identity token.

14. A computer-readable medium, characterized in that, The computer-readable medium stores a computer program that, when executed by a processor, implements the data communication method according to any one of claims 1 to 12.

15. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the executable instructions to implement the data communication method as described in any one of claims 1 to 12.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the data communication method according to any one of claims 1 to 12.