Cross-platform driver-free network card certificate reading method and device and medium

Abstract

The application provides a cross-platform driver-free network card certificate reading method and device and a medium, relates to the technical field of network access control, and the method comprises the steps of: constructing a virtual certificate address space in a network card firmware; receiving a target control message; when the network card firmware identifies the preset identification information, importing a certificate reading parameter of the target control message into the virtual certificate address space in the network card firmware, reading a target certificate data segment through mapping to an SPI storage chip; generating a plurality of response messages, writing the response messages into a network card receiving queue, making a network interface receive the plurality of response messages, and splicing the received plurality of response messages by a user state program to obtain complete certificate data. The application solves the technical problem in the prior art that, due to the fact that certificate reading relies on a special driver program, cross-platform reading needs to modify a network card driver program, and builds a virtual certificate address space and maps the virtual certificate address space to an SPI storage, thereby improving cross-platform compatibility.

Description

Technical Field

[0001] This application relates to the field of network access control technology, specifically to a cross-platform, driverless network card certificate reading method, device, and medium. Background Technology

[0002] In current network access authentication technologies, digital certificates, as core identity credentials, are typically stored in the operating system's certificate store or local file system. When upper-layer access authentication software needs to read these certificates, it must call the underlying network card driver through the operating system kernel to access hardware resources. However, due to significant differences in the kernel architecture and driver models of different operating systems, dedicated network card drivers need to be developed and maintained separately for each type of operating system. Furthermore, these drivers must undergo strict signature certification by the operating system vendor before they can be loaded. This not only leads to long development cycles and high maintenance costs but also introduces system stability risks caused by incompatibility between driver versions and operating system versions. Once a driver has a defect, it may directly lead to network interruption or even system crash, seriously affecting the reliability of certificate reading and the flexibility of cross-platform deployment.

[0003] In summary, existing technologies suffer from the technical problem that certificate reading relies on dedicated drivers, which necessitates modifications to the network card driver for cross-platform reading, further impacting the efficiency of network card certificate reading. Summary of the Invention

[0004] The purpose of this application is to provide a cross-platform, driverless network card certificate reading method, apparatus, and medium to solve the technical problem in the prior art that the certificate reading depends on a dedicated driver, which requires modification of the network card driver for cross-platform reading and further affects the efficiency of network card certificate reading.

[0005] To achieve the above objectives, this application provides a cross-platform, driverless network card certificate reading method, device, and medium.

[0006] Firstly, this application provides a cross-platform driverless network card certificate reading method. This method is implemented using a cross-platform driverless network card certificate reading device. The method includes: constructing a virtual certificate address space in the network card firmware, where the virtual certificate address space is mapped to the physical address of an external SPI storage chip connected to the network card; receiving a target control message sent by a user-mode program through a network interface, the target control message including preset identification information and certificate reading parameters; when the network card firmware identifies the preset identification information, importing the certificate reading parameters of the target control message into the virtual certificate address space in the network card firmware, and reading a target certificate data fragment by mapping it to the SPI storage chip; generating multiple response messages containing the target certificate data fragment, writing the multiple response messages into the network card receive queue, enabling the network interface to receive the multiple response messages, and the user-mode program concatenating the received multiple response messages to obtain complete certificate data.

[0007] Optionally, a target control message sent by a user-space program through a network interface is received, wherein the protocol type of the target control message is adaptively selected according to the operating system environment in which the user-space program resides; wherein the protocol type includes one or more of ICMP, UDP, or ARP protocols.

[0008] Optionally, the preset identification information includes a multi-field joint encoding structure, including a fixed preamble identifier, a certificate access type identifier, a segmented read sequence number, and an integrity verification field; the network card firmware parses the preset identification information of the target control message according to the multi-field joint encoding structure.

[0009] Optionally, the certificate reading parameters of the target control message are imported into the virtual certificate address space in the network card firmware, the virtual certificate address space including multiple logical segments; the certificate reading parameters of the target control message are parsed, the certificate reading parameters including virtual address offset, read length and access type identifier; segment matching is performed in the multiple logical segments according to the virtual address offset of the certificate reading parameters to obtain the matching segment identifier; the access control policy of the matching segment identifier is loaded, and the target certificate data fragment is read from the SPI memory chip under the access control policy.

[0010] Optionally, the plurality of logical segments include a certificate area, a private key index area, and a metadata area, and the plurality of logical segments include a plurality of physical address ranges that have a mapping relationship with the physical address of the external SPI storage chip of the network card.

[0011] Optionally, based on the matching segment identifier, a matching physical address range is obtained; the certificate reading parameters are fragmented according to a preset fragmentation granularity to obtain multiple fragment data; the fragment start address of each fragment data is calculated under the matching physical address range; the multiple fragment data are read through the SPI controller to output the target certificate data fragment.

[0012] Optionally, the network card firmware generates random data and sends it to the user-space program, the random data including random numbers and timestamp information; it receives response data generated by the user-space program processing the random data based on a preset private key; the network card firmware determines the corresponding preset public key according to the private key identifier information in the private key index area, verifies the response data in the metadata area based on the preset public key, and accesses the certificate area to read the target certificate data fragment when the verification is successful.

[0013] Optionally, the plurality of response messages are obtained by encoding the target certificate data fragment using an implicit channel coding method; wherein, the parameters of the implicit channel coding method include at least one of the following: response message length, the time interval between sending adjacent response messages, and changes in the message verification field.

[0014] Secondly, this application also provides a cross-platform driverless network card certificate reading device for executing the cross-platform driverless network card certificate reading method as described in the first aspect. The cross-platform driverless network card certificate reading device includes: a space construction module for constructing a virtual certificate address space in the network card firmware, wherein the virtual certificate address space is mapped to the physical address of an external SPI storage chip of the network card; a message receiving module for receiving a target control message sent by a user-mode program through a network interface, wherein the target control message includes preset identification information and certificate reading parameters; a message processing module for importing the certificate reading parameters of the target control message into the virtual certificate address space in the network card firmware when the network card firmware recognizes the preset identification information, and reading the target certificate data fragment by mapping it to the SPI storage chip; and a message response module for generating multiple response messages containing the target certificate data fragment, writing the multiple response messages into the network card receive queue, enabling the network interface to receive the multiple response messages, and having the user-mode program concatenate the received multiple response messages to obtain complete certificate data.

[0015] Thirdly, a computer-readable storage medium storing a computer program, which, when executed, implements the steps of the cross-platform driverless network card certificate reading method described in any one of the first aspects above.

[0016] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0017] By constructing a virtual certificate address space in the network interface card (NIC) firmware, which maps to the physical address of the external SPI storage chip, the system receives target control messages sent by a user-space program through the network interface. These messages include preset identification information and certificate reading parameters. When the NIC firmware recognizes the preset identification information, it imports the certificate reading parameters of the target control message into the virtual certificate address space within the firmware. The target certificate data fragment is then read from the SPI storage chip via mapping. Multiple response messages containing the target certificate data fragment are generated and written into the NIC's receive queue, allowing the network interface to receive these messages. The user-space program then concatenates these response messages to obtain complete certificate data. In other words, by constructing a virtual certificate address space in the NIC firmware and establishing a secure authentication data channel between user space and firmware using standard network protocol messages, cross-platform secure reading of hardware certificates can be achieved without modifying the operating system driver. This improves cross-platform compatibility and enhances the efficiency and security of NIC certificate reading.

[0018] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating the cross-platform, driverless network card certificate reading method described in this application.

[0021] Figure 2 This is a schematic diagram of the cross-platform, driverless network card certificate reading device of this application.

[0022] Explanation of reference numerals in the attached diagram: Space construction module 11, Message receiving module 12, Message processing module 13, Message response module 14. Detailed Implementation

[0023] This application provides a cross-platform, driverless network interface card (NIC) certificate reading method, apparatus, and medium, solving the technical problem in existing technologies where certificate reading relies on dedicated drivers, requiring modifications to the NIC driver for cross-platform reading and further impacting certificate reading efficiency. By constructing a virtual certificate address space in the NIC firmware and establishing a secure authentication data channel between user space and firmware using standard network protocol messages, secure cross-platform reading of hardware certificates can be achieved without modifying the operating system driver, improving cross-platform compatibility and thus enhancing the efficiency and security of NIC certificate reading.

[0024] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be understood that this application is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. It should also be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all of them.

[0025] Example 1, please refer to the appendix. Figure 1 This application provides a cross-platform driverless network card certificate reading method, wherein the cross-platform driverless network card certificate reading method is applied to a cross-platform driverless network card certificate reading device, and the cross-platform driverless network card certificate reading method specifically includes the following steps:

[0026] A virtual certificate address space is constructed in the network card firmware, and the virtual certificate address space is mapped to the physical address of the external SPI storage chip of the network card.

[0027] Specifically, during the network interface card (NIC) firmware development phase, according to the security plan, a dedicated physical storage area is allocated on the SPI memory chip to store certificate data. A clearly structured data structure is defined in the firmware source code to represent the virtual certificate address space, logically divided into contiguous blocks. For example, the first 64 kilobytes are defined as the certificate area, the following 4 kilobytes as the private key index area, and the next 4 kilobytes as the metadata area. The starting address of the virtual certificate address space is set to zero, and its capacity is set to the same as the physical chip capacity to ensure that all physical storage areas are logically covered.

[0028] When the network card firmware boots up, it runs an initialization function that, based on preset partitioning rules, precisely calculates the physical start address and length of the SPI chip corresponding to each logical block in the virtual address space, and fills these mappings into a static array or linked list. When other modules of the firmware need to access certificate data, they only need to pass in a virtual address. The firmware's address management module will then query this mapping table, convert the virtual address into a specific SPI physical address, and then call the underlying SPI controller driver to initiate the actual read / write operation on that physical address. The entire process ensures that the upper-layer logic only interacts with fixed virtual addresses and does not need to care about the actual storage location of the certificate data in the physical chip.

[0029] The physical storage details of the certificate are completely hidden from upper-layer applications. Regardless of changes in the physical chip's address or whether the storage areas are physically contiguous, the upper layer accesses the certificate through a unified virtual address, improving design flexibility and maintainability. Whenever subsequent functional modules within the firmware need to access certificate data, they only need to provide the virtual address, and the firmware will automatically calculate the actual physical address based on the mapping table and initiate the corresponding read / write operation through the SPI controller.

[0030] Receive a target control message sent by a user-space program through a network interface. The target control message includes preset identification information and certificate reading parameters.

[0031] Furthermore, this application also includes the following steps: receiving a target control message sent by a user-space program through a network interface, wherein the protocol type of the target control message is adaptively selected according to the operating system environment in which the user-space program resides; wherein the protocol type includes one or more of ICMP protocol, UDP protocol or ARP protocol.

[0032] Furthermore, this application also includes the following steps: the preset identification information includes a multi-field joint encoding structure, including a fixed preamble identifier, a certificate access type identifier, a segmented reading sequence number, and an integrity verification field; the network card firmware parses the preset identification information of the target control message according to the multi-field joint encoding structure.

[0033] Specifically, on the user-space program side, upon startup, it checks the operating system environment in which it is running. For example, it attempts to send a test ICMP message. If it finds that the message is blocked by a firewall or times out, it automatically switches to the UDP protocol to attempt a similar message. If UDP is also restricted, it further downgrades to the ARP protocol, thus ensuring that at least one protocol can reach the network card firmware. After determining which protocol to use, the user-space program begins to construct the target control message.

[0034] ICMP (Internet Control Message Protocol) is a core protocol of the TCP / IP protocol suite, commonly used to transmit control and status information. For example, the frequently used ping command uses ICMP echo request / response messages and can usually be processed directly by the system kernel. UDP (User Datagram Protocol) is a connectionless transport layer protocol that provides simple, unreliable datagram services. Sending UDP packets usually requires binding to a specific port. ARP (Address Resolution Protocol) is used to obtain the corresponding MAC address from an IP address. ARP request / response messages are broadcast at the data link layer, without passing through the network layer or higher protocol stacks.

[0035] The program calculates the number of transmissions required based on the certificate length to be read and assigns an incrementing segment read sequence number to the current message. A multi-field combined encoding structure is formed by combining a fixed preamble, certificate access type identifier, segment read sequence number, and integrity check field calculated based on the message content, and placed at the very beginning of the message's data payload. Following the encoding structure, the program fills in the certificate read parameters, including the virtual address offset and the expected data length. After the message is constructed, the user-space program sends the message to the designated network interface through the socket interface provided by the operating system. The fixed preamble is the starting part of the multi-field joint encoding structure. It is usually a set of fixed special values ​​used by the firmware to quickly locate the beginning of the message and perform preliminary identification. The certificate access type identifier is a field used to indicate the specific intention of this operation, such as reading a certificate, verifying identity, or obtaining metadata. The segment read sequence number is a numerical number used to identify which segment the current message belongs to in the entire read task, which facilitates data alignment between the firmware and user-space programs during multiple transmissions. The integrity check field is a checksum used to verify whether errors have occurred in the message during transmission. It is usually calculated based on the message content. After receiving the message, the firmware will recalculate it and compare it with this field.

[0036] Upon receiving a target control message, the network interface card (NIC) firmware first performs a standard cyclic redundancy check (CRC) and, if successful, places the message in the receive queue. While polling the receive queue, the NIC firmware retrieves the message and first extracts its data payload. Based on a pre-defined format, the NIC firmware parses the multi-field combined encoding structure from the beginning of the data payload. It checks if the fixed preamble matches the preset magic number; if not, it's considered a normal data packet and allowed to proceed for normal processing by the operating system. If a match is found, the NIC firmware continues parsing the certificate access type identifier to determine if the request is a legitimate read operation. The NIC extracts and records the segment read sequence number for subsequent order control when organizing response messages. It recalculates the integrity check value based on the message content and compares it with the integrity check field in the message; if they match, it confirms the message has not been tampered with during transmission. After parsing, the firmware extracts the certificate read parameters from the remaining portion of the message data payload. Preset identification information is a specific data pattern embedded in the packet data payload. It allows the network card firmware to accurately identify a command message from massive network traffic rather than a regular data packet. It typically uses a magic number that is less likely to be confused with normal communication data. Certificate read parameters are data carried in the packet by the user-space program to describe the specific requirements of this read operation. They include at least the starting read position in the virtual address space and the length of data to be read. For example, a user-space access authentication program needs to read certificate data stored at offset 50,000 bytes in the network card's virtual address space. A 1500-byte buffer is created in memory, and the preset identification information 0x5A5A5A5A is filled into the first four bytes of the buffer. The certificate read parameters are then filled into the following eight bytes, with the first four bytes filled with the virtual address offset of 50,000 and the last four bytes filled with the expected data length of 1400 bytes. A UDP socket is created, and the target IP address is set to the network card's actual IP address 192.168.1.100, and the target port number is set to the dedicated command receiving port 35000. The send function is called to send the entire 1500-byte buffer as the data payload. The network interface card (NIC) hardware correctly receives the UDP packet and, after passing cyclic redundancy check (CRC), places it into the receive descriptor ring. The NIC firmware polls for new packets, reads the complete packet from the receive buffer, extracts the data payload, and retrieves the first four bytes (0x5A5A5A5A) from the payload. This data is compared with a preset identifier stored in the firmware, confirming a successful match. The firmware then parses the virtual address offset (50000) and read length (1400 bytes) from the subsequent eight bytes, preparing to perform the read operation.

[0037] By directly constructing and sending network packets containing specific identifiers and parameters through user-space programs, a software communication tunnel was successfully established from the upper-layer application to the lower-layer network card firmware. The entire process relies entirely on the operating system's standard network socket programming interface, without calling any proprietary driver input / output control commands. This completely bypasses the challenges of kernel driver adaptation, allowing the same set of user-space code to be compiled and run on different operating systems, achieving true cross-platform driverless communication. The introduction of preset identification information enables the network card firmware to accurately distinguish between ordinary network traffic and control commands, avoiding misprocessing of normal data packets by the firmware.

[0038] When the network card firmware recognizes the preset identification information, it imports the certificate reading parameters of the target control message into the virtual certificate address space in the network card firmware, and reads the target certificate data fragment by mapping it to the SPI storage chip.

[0039] Furthermore, this application also includes the following steps: importing the certificate reading parameters of the target control message into the virtual certificate address space in the network card firmware, the virtual certificate address space including multiple logical segments; parsing the certificate reading parameters of the target control message, the certificate reading parameters including virtual address offset, read length and access type identifier; performing segment matching in the multiple logical segments according to the virtual address offset of the certificate reading parameters to obtain the matching segment identifier; loading the access control policy of the matching segment identifier, and mapping it to the SPI memory chip to read the target certificate data fragment under the access control policy.

[0040] Furthermore, this application also includes the following steps: the plurality of logical segments include a certificate area, a private key index area, and a metadata area, and the plurality of logical segments include a plurality of physical address ranges that have a mapping relationship with the physical address of the external SPI storage chip of the network card.

[0041] Specifically, after identifying the target control message using preset identification information, the network interface card (NIC) firmware extracts complete certificate reading parameters from the message data payload, including the virtual address offset for this operation, the expected data length to be read, and the access type identifier. The NIC firmware internally maintains a logical segment description table, recording the name, starting virtual address, ending virtual address, and corresponding physical address range of each logical segment in the virtual certificate address space.

[0042] The parsed virtual address offset is compared with each entry in the logical segment description table, checking if the offset is greater than or equal to the start virtual address of a segment and less than the end virtual address of that segment. When a matching segment is found, the firmware records the segment's identification information, such as number one representing the certificate area, number two representing the private key index area, and number three representing the metadata area. If no match is found after traversing all segments, the access is deemed invalid and the packet is discarded.

[0043] The virtual certificate address space is a logical address range built within the network interface card (NIC) firmware. It is divided into multiple functionally distinct logical segments, each corresponding to a specific data type or function. These segments include the certificate area, private key index area, and metadata area. The certificate area is a logical region within the virtual address space specifically for storing the digital certificate itself; this area typically contains large amounts of data that need to be frequently accessed. The private key index area is a logical region within the virtual address space specifically for storing key identification information, used to find the corresponding public key during subsequent authentication. The metadata area is a logical region within the virtual address space specifically for storing configuration information such as access control policies, timestamp validity periods, and authentication algorithm identifiers. These logical segments include multiple physical address ranges that map to the physical addresses of the external SPI storage chip connected to the NIC. In other words, each logical segment represents a specific physical address range on the SPI storage chip. The firmware uses this mapping to translate virtual addresses into physical addresses for reading and writing.

[0044] After successfully obtaining the matching segment identifier, the network interface card (NIC) firmware does not immediately perform a read operation. Instead, it first loads the access control policy associated with that segment, which is pre-stored in the firmware's configuration or metadata area and contains the access permission rules for that segment. The NIC firmware compares the access type identifier in this request with the allowed operation types in the policy, such as checking whether a read operation is currently allowed, or whether authentication is required for the private key index area. If the access type identifier does not match the policy, or if the policy requires authentication but this request does not include an authentication success flag, the firmware rejects the read request and may return an error response.

[0045] Once the access control policy verification is successful, the firmware begins the actual data reading. Based on the matching segment identifier, it locates the corresponding physical address range. Then, based on the difference between the virtual address offset and the starting address of the segment, it calculates the specific offset position in the physical address space. Subtracting the starting virtual address of the segment from the virtual address offset yields the relative offset within the segment. This relative offset is then added to the starting physical address of the segment to obtain the starting physical address for this read. Using the SPI controller, data is continuously read from the SPI memory chip starting from this starting physical address, according to the read length, ultimately obtaining the target certificate data segment.

[0046] By dividing the virtual certificate address space into multiple logically defined segments and combining segment matching with access control policy loading mechanisms, hierarchical and categorized management of different types of sensitive data is achieved. The certificate area, private key index area, and metadata area each have independent access rules. The private key index area can be configured to allow access only after identity verification, and the metadata area can be configured to be read-only to prevent tampering, thus significantly improving the overall security of hardware certificate storage. Through precise conversion of virtual address offsets to physical addresses, it is ensured that the network card firmware can accurately locate and read the required data from the SPI chip, providing a reliable data source for upper-layer user-space programs.

[0047] Furthermore, this application also includes the following steps: obtaining a matching physical address range based on the matching segment identifier; fragmenting the reading length of the certificate reading parameters according to a preset fragmentation granularity to obtain multiple fragment data; calculating the fragment start address of each fragment data under the matching physical address range; reading the multiple fragment data through the SPI controller; and outputting the target certificate data fragment.

[0048] Specifically, the network card firmware queries and obtains the corresponding matching physical address range from the internally maintained address mapping table based on the matching segment identifier, clearly giving the physical start and end addresses of the data involved in this operation on the SPI chip, ensuring that all subsequent read operations are performed within this legal address range, and preventing out-of-bounds access from damaging data in other areas.

[0049] The firmware processes the read length parameter in the certificate read parameters sent by the user-space program. Since the amount of data that a single network packet can carry is limited, while the total length of the certificate may be large, the firmware needs to break down a large read request into multiple smaller read operations. The firmware reads the preset fragmentation granularity configured internally, such as the security data length obtained by subtracting the overhead of each protocol layer from the maximum transmission unit of the network packet. The network card firmware divides the total read length by the preset fragmentation granularity to calculate the number of fragments required, and handles any remainders to ensure that the last fragment can read all the remaining data, thus obtaining descriptive information for multiple fragments. Each fragment contains the length to be read and its sequential number in the entire read task.

[0050] Each data fragment is processed cyclically. For the current fragment, the network interface card (NIC) firmware calculates the segment start address in the physical address space based on its order in the entire read task. The calculation method is based on the start address matching the physical address range, plus the total virtual address offset relative to the segment start, plus the cumulative length of all previously completed fragments. After obtaining the segment start address, the command code, target address, and read length for this read operation are set by configuring the SPI controller registers, and SPI data transmission is initiated. The SPI controller communicates with the external SPI flash chip according to the timing protocol, reading data byte by byte from the specified address back to the temporary buffer inside the firmware. After completing one read, the NIC firmware temporarily stores the obtained fragment data along with its sequence number, ready for use in constructing subsequent response messages. The NIC firmware repeats the above process of calculating the address and initiating SPI reads until all fragment data has been read, ultimately obtaining a complete set of target certificate data fragments.

[0051] For example, the physical address range is matched to the certificate area, with a physical start address of 0xF00000 (decimal 15728640) and an end address of 0xFDFFFF. The virtual address offset is 0x30000 (decimal 196608), and the read length is 2500 bytes. The preset fragment granularity is 1024 bytes. The firmware confirms that the current area is the certificate area, with a physical address range of 0xF00000 to 0xFDFFFF. The physical base address is 0xF00000. The total fragment length is calculated to be 2500 bytes, the fragment granularity to be 1024 bytes, the number of complete fragments to be 2500 / 1024 = 2 fragments, and the tail fragment length to be 2500 - 2 * 1024 = 452 bytes. Therefore, a total of 3 fragment data are generated: fragment 0 (1024B), fragment 1 (1024B), and fragment 2 (452B). Calculate the starting address of each fragment: offset within the user-requested segment is 0x30000; the starting physical address of the first fragment is 0xF30000; the starting physical address of the second fragment is 0xF30400; and the starting physical address of the third fragment (tail fragment) is 0xF30800. Prepare a 1024-byte buffer. To read fragment 0, the network card sends command 0x03 to the chip via the SPI controller, followed by address 0x00F30000, and then continuously reads 1024 bytes of data into the buffer. This 1024 bytes constitute the first target certificate data fragment. To read fragment 1, the network card firmware sends command 0x03, address 0x00F30400, and reads 1024 bytes, obtaining the second data fragment. To read fragment 2, the network card firmware sends command 0x03, address 0x00F30800, and reads 452 bytes, obtaining the third data fragment. During the reading process, the SPI controller returns a status after each operation, and the firmware needs to verify whether the reading was successful. The firmware temporarily stores a total of 2500 bytes of data in sequence (segment 0, segment 1, segment 2), which is used to encapsulate the target certificate data fragment set returned in the response message.

[0052] By breaking down large read requests into multiple smaller requests that conform to the optimal operating size of the SPI controller, the risk of single-operation failure is reduced, and the reliability of data transmission in environments with potential signal interference is improved. If a fragment read fails, only that fragment can be retried without retransmitting the entire large data block. The network interface card firmware reads data from the SPI chip in batches, based on the size that a standard network packet can carry, ensuring that each fragment can be successfully encapsulated into subsequent response packets, avoiding the risk of packets being fragmented or discarded by the network protocol stack due to excessive data length. Precise calculation based on the physical address range ensures accurate positioning for each read, preventing data misalignment or omission due to fragmentation operations.

[0053] Furthermore, this application also includes the following steps: the network card firmware generates random data and sends it to the user-space program, the random data including random numbers and timestamp information; receives response data generated by the user-space program processing the random data based on a preset private key; the network card firmware determines the corresponding preset public key according to the private key identifier information in the private key index area, verifies the response data in the metadata area based on the preset public key, and accesses the certificate area to read the target certificate data fragment when the verification is successful.

[0054] Specifically, when the network interface card (NIC) firmware receives an initial read request from a user-space program or detects that the current session has not yet been authenticated, it initiates an identity challenge process. The NIC firmware calls its internal hardware random number generator to generate a sufficiently long random number, and simultaneously reads the current timestamp from the firmware's real-time clock module. The random number and timestamp are combined into a complete data segment. A special response message is constructed and sent to the user-space program, awaiting its reply. The random data is an unpredictable sequence of data generated by the NIC firmware for identity challenges, typically containing a random number and a timestamp to ensure the uniqueness and timeliness of each challenge. The random number is an irregular value generated by the firmware's built-in hardware random number generator to prevent replay attacks and ensure the randomness of each authentication session; the timestamp is the time value recorded by the firmware at the moment the data was generated, preventing expired authentication requests from being maliciously exploited.

[0055] After receiving a message containing random data, the user-space program extracts the random number and timestamp information, calls its internally integrated encryption algorithm library, and uses its stored preset private key to sign or encrypt the entire received random data block, generating response data that cannot be directly deciphered. This response data is then encapsulated into a new control message and sent back to the network interface card (NIC) firmware via the network interface. The preset private key is a private key stored within the user-space program. This key, together with the public key stored in the NIC firmware, forms an asymmetric key pair used to prove the user-space program's legitimate identity. The response data is the ciphertext result generated by the user-space program after receiving the random data and encrypting it using the preset private key, used to prove to the firmware that it possesses the correct private key.

[0056] After receiving a message containing response data, the network interface card (NIC) firmware extracts the response data, verifies its legitimacy, and finds the correct public key. The NIC firmware accesses the private key index area in the virtual certificate address space. Based on the context of the current session or the key identifier information carried in the message, it reads the corresponding private key identifier from the private key index area and locates the storage location of the preset public key using the private key identifier. The preset public key is then loaded into the firmware's internal encryption engine. The private key index area is a logical segment in the virtual certificate address space that stores index information used to identify different keys. The NIC firmware can use these indexes to find the corresponding public key storage location. The preset public key is the public key corresponding to the private key held by the user-space program. It is pre-stored in the NIC firmware or loaded securely from the SPI chip and is used to decrypt the response data and verify its legitimacy.

[0057] Before officially starting the decryption and verification process, the authentication parameter information stored in the metadata area is loaded, and the timestamp validity period and authentication algorithm identifier are read. The metadata area is a logical segment in the virtual certificate address space that stores authentication-related configuration parameters, including the timestamp validity period and authentication algorithm identifier. The authentication parameter information is a set of rule-based data stored in the metadata area, used to guide the firmware on how to perform the verification operation, such as the maximum allowed time deviation and the required encryption algorithm type. The timestamp validity period is a value in the authentication parameter information that specifies the maximum allowed difference between the timestamp carried in the random data and the firmware's current time; exceeding this difference indicates that the response has expired. The authentication algorithm identifier is an encoding in the authentication parameter information used to specify the type of encryption algorithm that must be used for this verification, such as whether to use RSA or elliptic curve cryptography, ensuring that the firmware uses the correct method for decryption and comparison.

[0058] The decrypted timestamp information is compared with the firmware's current real-time clock time, and the time difference between the two is calculated. This difference is then compared with the timestamp validity period read from the metadata area. If the time difference is greater than the timestamp validity period, the response is considered expired, and the verification result is failed. If the time difference is within the timestamp validity period, the firmware further compares the decrypted random number with the previously sent original random number byte by byte. If they match perfectly, it proves that the user-space program does indeed hold the correct private key corresponding to the public key, and the verification result is passed. If the random number comparison fails or the decryption process encounters an error, the verification result is failed.

[0059] Only if the verification result is successful will the network card firmware consider the current user-space program a legitimate authorized program, thus allowing it to continue executing subsequent operations. The network card firmware will then access the certificate area in the virtual certificate address space, begin executing the previously parsed certificate read parameters, and read the target certificate data fragment from the SPI storage chip. If the verification fails, the network card firmware will directly discard the request and will not return any certificate data, while recording an authentication failure event. In other words, only when the validity check passes and the signature verification is successful will the final conclusion of successful verification be reached. Once verification is successful, the firmware is authorized to execute the subsequent process, namely accessing the certificate area to read the target certificate data fragment requested by the user. If any step fails, the status will be "verification failed," the firmware will discard the request, record a security log, and will not perform any certificate data reading operations.

[0060] By introducing a challenge-response mechanism that includes random numbers and timestamps, and combining it with configuration information in the private key index and metadata areas, strong two-way authentication of user-space program identities is achieved. The use of random numbers effectively prevents attackers from deceiving the firmware by replaying previously intercepted legitimate response data, as the random number is different for each challenge. The introduction of timestamps and expiration dates ensures the timeliness of the authentication process; even if the private key is not cracked, expired response data cannot pass verification, further narrowing the attack window. Storing the public key index and authentication parameters in a dedicated segment of the virtual address space allows for flexible configuration of the firmware's verification logic, ensuring that only authorized programs that have undergone strict identity verification can ultimately access the sensitive certificate data stored in the hardware.

[0061] Multiple response messages containing the target certificate data fragment are generated, and the multiple response messages are written into the network card receive queue, so that the network interface receives the multiple response messages. The user-space program concatenates the received multiple response messages to obtain complete certificate data.

[0062] Furthermore, this application also includes the following steps: the plurality of response messages are obtained by encoding the target certificate data segment using an implicit channel coding method; wherein, the parameters of the implicit channel coding method include at least one of the following: response message length, the transmission time interval between adjacent response messages, and changes in the message verification field.

[0063] Specifically, after obtaining the complete set of target certificate data fragments through multiple SPI read operations, the network interface card (NIC) firmware enters the response message construction phase. A standard network message corresponding to the request type is created. For example, if the request is an ICMP echo request (Ping), an ICMP echo reply message is constructed; if the request is a UDP message, a UDP reply message with source / destination ports swapped is constructed. The source and destination addresses in the IP header are exchanged to ensure the response can be routed back to the user program socket that initiated the request.

[0064] Implicit channel coding (ECC) is an encoding method that transmits information by modifying certain external attributes of the message itself, rather than directly writing data into the message payload. These attributes are typically not directly monitored or analyzed by conventional network monitoring and analysis tools. The parameters of implicit channel coding include at least one of the following: response message length, the time interval between adjacent response messages, and changes to the message checksum. The response message length, as one of the implicit channel coding parameters, is the total number of bytes in the network message. Additional information is encoded by intentionally controlling the precise length of each response message. The time interval between adjacent response messages, also an implicit channel coding parameter, is the time difference between the firmware writing two consecutive response messages to the receive queue. This interval is controlled by a precise timer to transmit information. Changes to the message checksum are specific variations in the cyclic redundancy check (CRC) value at the end of the network message, another implicit channel coding parameter. These variations are fine-tuned based on the hardware's automatic checksum calculation, allowing certain bits of the checksum to carry information.

[0065] By employing implicit channel coding, key control information such as fragmentation order and integrity verification is injected into the application layer payload of the message.

[0066] After the network interface card (NIC) firmware includes certificate data fragments in the payload, it appends padding bytes of a specific length. The certificate data portion of all fragments has a fixed length, but the padding length varies. For example, a fragment with sequence number N is specified to have a padding length of 8N bytes. The fragment sequence number can be deduced from the payload length obtained by the user program. It is essential to ensure that the total encoded payload length is less than the path MTU.

[0067] When the network interface card (NIC) firmware embeds a field (e.g., 8 bytes) at the beginning of the payload, before the certificate data, containing a high-precision monotonically increasing counter value or a firmware clock timestamp, this timestamp represents the theoretical transmission time when the firmware constructs the message. User programs can verify the order and continuity of messages by comparing the difference in these timestamps between adjacent messages, thus mitigating replay attacks. The timestamp itself can also implicitly contain sequence information.

[0068] When the network interface card (NIC) firmware reaches the end of the payload, after the certificate data, it calculates a checksum (such as CRC32) specific to the certificate data fragment. Then, it performs a reversible operation on this checksum and the current fragment sequence number, storing the result as the final field in the message. Upon receiving the message, the user program recalculates the CRC32 of the certificate data and performs the inverse operation on the field in the message (e.g., XORing the result with the same value) to determine the sequence number, thus verifying data integrity.

[0069] The Ethernet frame, containing the destination MAC address, IP header, transport layer header, and encoded payload, is directly written to the memory space pointed to by the next free descriptor in the receive ring buffer managed by the network card driver. The firmware then updates the descriptor's status to ready and transfers ownership to the host driver, simulating the hardware behavior of receiving a new data packet from an external network. The host's network driver finds this ready descriptor during polling and reads the data into the kernel via DMA. The kernel network protocol stack parses it layer by layer like a normal receive packet, ultimately delivering it to the user-space program that is currently blocking reception.

[0070] After receiving the first message, the user-space program decodes it according to the agreed implicit encoding rules. If it is length-encoded, it checks the length of the received payload and decodes the sequence number N; if it is timestamp-encoded, it reads the embedded timestamp and records the order; if it is checksum and watermark-encoded, it decodes the sequence number N from the watermark. The program uses the decoded sequence number N as an index to store the certificate data fragments in the message payload in the buffer at position N. This process is repeated until the program determines that all fragments have been received according to a specific rule, such as receiving an end packet with a special encoded length. Finally, the program concatenates the data in the buffer in sequence number order to reconstruct the complete certificate.

[0071] By employing implicit channel coding to transmit certificate data fragments, reliable delivery of fragmentation order information and control signaling is achieved without increasing additional message load. Even if the network environment performs deep inspection or filtering of message content, attackers cannot easily identify that certificate data is being transmitted, because key information is hidden in external attributes such as message length and time intervals, enhancing the stealth and security of communication.

[0072] In summary, the cross-platform, driverless network card certificate reading method provided in this application has the following technical advantages:

[0073] By constructing a virtual certificate address space in the network interface card (NIC) firmware, which maps to the physical address of the external SPI storage chip, the system receives target control messages sent by a user-space program through the network interface. These messages include preset identification information and certificate reading parameters. When the NIC firmware recognizes the preset identification information, it imports the certificate reading parameters of the target control message into the virtual certificate address space within the firmware. The target certificate data fragment is then read from the SPI storage chip via mapping. Multiple response messages containing the target certificate data fragment are generated and written into the NIC's receive queue, allowing the network interface to receive these messages. The user-space program then concatenates these response messages to obtain complete certificate data. In other words, by constructing a virtual certificate address space in the NIC firmware and establishing a secure authentication data channel between user space and firmware using standard network protocol messages, cross-platform secure reading of hardware certificates can be achieved without modifying the operating system driver. This improves cross-platform compatibility and enhances the efficiency and security of NIC certificate reading.

[0074] Example 2: Based on the same inventive concept as the cross-platform driverless network card certificate reading method in Example 1, this application also provides a cross-platform driverless network card certificate reading device. Please refer to the appendix. Figure 2 The cross-platform, driverless network card certificate reading device includes:

[0075] The network interface card (NIC) firmware includes a virtual certificate address space module 11, which is used to construct a virtual certificate address space in the NIC firmware. This virtual certificate address space is mapped to the physical address of the external SPI storage chip connected to the NIC. The message receiving module 12 is used to receive target control messages sent by a user-mode program through the network interface. These target control messages include preset identification information and certificate reading parameters. The message processing module 13 is used to import the certificate reading parameters of the target control message into the virtual certificate address space in the NIC firmware when the NIC firmware recognizes the preset identification information, and then read the target certificate data fragment by mapping it to the SPI storage chip. The message response module 14 is used to generate multiple response messages containing the target certificate data fragment, write these multiple response messages into the NIC receive queue, and enable the network interface to receive multiple response messages. The user-mode program then concatenates the received multiple response messages to obtain complete certificate data.

[0076] Furthermore, the message receiving module 12 in the cross-platform driverless network card certificate reading device is also used to: receive target control messages sent by user-mode programs through network interfaces, wherein the protocol type of the target control message is adaptively selected according to the operating system environment where the user-mode program is located; wherein the protocol type includes one or more of ICMP protocol, UDP protocol or ARP protocol.

[0077] Furthermore, the message receiving module 12 in the cross-platform driverless network card certificate reading device is also used for: the preset identification information includes a multi-field joint encoding structure, including a fixed preamble identifier, a certificate access type identifier, a segmented reading sequence number, and an integrity verification field; the network card firmware parses the preset identification information of the target control message according to the multi-field joint encoding structure.

[0078] Furthermore, the message processing module 13 in the cross-platform driverless network card certificate reading device is also used to: import the certificate reading parameters of the target control message into the virtual certificate address space in the network card firmware, the virtual certificate address space including multiple logical segments; parse the certificate reading parameters of the target control message, the certificate reading parameters including virtual address offset, reading length and access type identifier; perform segment matching in the multiple logical segments according to the virtual address offset of the certificate reading parameters to obtain the matching segment identifier; load the access control policy of the matching segment identifier, and map it to the SPI memory chip to read the target certificate data fragment under the access control policy.

[0079] Furthermore, the message processing module 13 in the cross-platform driverless network card certificate reading device is also used to: the plurality of logical segments include a certificate area, a private key index area and a metadata area, and the plurality of logical segments include a plurality of physical address ranges that have a mapping relationship with the physical address of the external SPI storage chip of the network card.

[0080] Furthermore, the message processing module 13 in the cross-platform driverless network card certificate reading device is also used to: obtain the matching physical address range according to the matching segment identifier; divide the reading length of the certificate reading parameter into fragments according to the preset fragmentation granularity to obtain multiple fragment data; calculate the fragment start address of each fragment data under the matching physical address range; read the multiple fragment data through the SPI controller; and output the target certificate data fragment.

[0081] Furthermore, the message processing module 13 in the cross-platform driverless network card certificate reading device is also used for: generating random data from the network card firmware and sending it to the user-space program, the random data including random numbers and timestamp information; receiving response data generated by the user-space program processing the random data based on a preset private key; the network card firmware determining the corresponding preset public key according to the private key identifier information in the private key index area, verifying the response data in the metadata area based on the preset public key, and accessing the certificate area to read the target certificate data fragment when the verification is successful.

[0082] Furthermore, the message response module 14 in the cross-platform driverless network card certificate reading device is also used to: obtain the target certificate data fragment by encoding the multiple response messages using an implicit channel coding method; wherein, the parameters of the implicit channel coding method include at least one of the following: response message length, the sending time interval between adjacent response messages, and changes in the message verification field.

[0083] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The cross-platform driverless network card certificate reading method and specific examples in the aforementioned embodiment one are also applicable to the cross-platform driverless network card certificate reading device of this embodiment. Through the foregoing detailed description of the cross-platform driverless network card certificate reading method, those skilled in the art can clearly understand the cross-platform driverless network card certificate reading device of this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0084] In Embodiment 3, based on the same inventive concept as the cross-platform driverless network card certificate reading method in Embodiment 1, this application also provides a computer-readable storage medium storing a computer program, which, when executed, implements the steps of any one of the cross-platform driverless network card certificate reading methods in Embodiment 1.

[0085] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0086] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application also intends to include such modifications and variations.

Claims

1. A cross-platform, driverless method for reading network card certificates, characterized in that, include: A virtual certificate address space is constructed in the network card firmware, and the virtual certificate address space is mapped to the physical address of the external SPI storage chip of the network card; Receive a target control message sent by a user-space program through a network interface, the target control message including preset identification information and certificate reading parameters; When the network interface card (NIC) firmware recognizes the preset identification information, it imports the certificate reading parameters of the target control message into the virtual certificate address space in the NIC firmware, and reads the target certificate data fragment by mapping it to the SPI storage chip, including: The virtual certificate address space includes multiple logical segments; Parse the certificate read parameters of the target control message, which include virtual address offset, read length, and access type identifier; Based on the virtual address offset of the certificate reading parameters, segment matching is performed in the multiple logical segments to obtain the matching segment identifier; Load the access control policy of the matching segment identifier, and under the access control policy, map it to the SPI memory chip to read the target certificate data segment; Multiple response messages containing the target certificate data fragment are generated, and the multiple response messages are written into the network card receive queue, so that the network interface receives the multiple response messages. The user-space program concatenates the received multiple response messages to obtain complete certificate data.

2. The cross-platform driverless network card certificate reading method as described in claim 1, characterized in that, The plurality of logical segments include a certificate area, a private key index area, and a metadata area, and the plurality of logical segments include a plurality of physical address ranges that have a mapping relationship with the physical address of the external SPI storage chip of the network card.

3. The cross-platform driverless network card certificate reading method as described in claim 2, characterized in that, The method of reading the target certificate data fragment by mapping it to the SPI memory chip includes: Based on the matching segment identifier, obtain the matching physical address range; The certificate reading parameters are fragmented according to the preset fragmentation granularity to obtain multiple fragment data; Calculate the starting address of each data fragment within the matching physical address range, read the multiple data fragments through the SPI controller, and output the target certificate data fragment.

4. The cross-platform driverless network card certificate reading method as described in claim 2, characterized in that, Before reading the target certificate data fragment, the method also includes: The network card firmware generates random data and sends it to the user-space program. The random data includes random numbers and timestamp information. Receive response data generated by the user-space program processing the random data based on a preset private key; The network card firmware determines the corresponding preset public key based on the private key identifier information in the private key index area, verifies the response data in the metadata area based on the preset public key, and accesses the certificate area to read the target certificate data fragment when the verification is successful.

5. The cross-platform driverless network card certificate reading method as described in claim 1, characterized in that, The multiple response messages are obtained by encoding the target certificate data fragment using implicit channel coding. The parameters of the implicit channel coding method include at least one of the following: response message length, time interval between sending adjacent response messages, and changes in the message check field.

6. The cross-platform driverless network card certificate reading method as described in claim 1, characterized in that, Receive target control messages sent by user-mode programs through a network interface, wherein the protocol type of the target control messages is adaptively selected according to the operating system environment in which the user-mode programs reside; The protocol type includes one or more of the following: ICMP protocol, UDP protocol, or ARP protocol.

7. The cross-platform driverless network card certificate reading method as described in claim 1, characterized in that, The preset identification information includes a multi-field joint encoding structure, including a fixed preamble identifier, a certificate access type identifier, a segmented reading sequence number, and an integrity verification field; The network card firmware parses the target control message using the preset identification information based on the multi-field joint encoding structure.

8. A cross-platform, driverless network card certificate reading device, characterized in that, The step of implementing the cross-platform driverless network card certificate reading method according to any one of claims 1 to 7, wherein the cross-platform driverless network card certificate reading device comprises: The space construction module is used to construct a virtual certificate address space in the network card firmware. The virtual certificate address space is mapped to the physical address of the external SPI storage chip of the network card. The message receiving module is used to receive target control messages sent by user-space programs through a network interface. The target control messages include preset identification information and certificate reading parameters. The message processing module is used to import the certificate reading parameters of the target control message into the virtual certificate address space in the network card firmware when the network card firmware recognizes the preset identification information, and read the target certificate data fragment by mapping it to the SPI storage chip. The message response module is used to generate multiple response messages containing the target certificate data fragment, write the multiple response messages into the network card receive queue, enable the network interface to receive the multiple response messages, and the user-space program concatenates the received multiple response messages to obtain complete certificate data.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed, implements the steps of the cross-platform driverless network card certificate reading method according to any one of claims 1 to 7.

Images