A safety authentication test method and system for a vehicle-mounted controller and a vehicle

Abstract

This application provides a security authentication testing method, system, and vehicle for an on-board controller. The method includes: establishing a fixed-point simulation model of a key generation algorithm in a simulation modeling environment and converting it into target code, which is then burned into the controller; placing the controller on a hardware-in-the-loop test platform; the hardware-in-the-loop test platform sending a seed request to the controller; the controller responding to the seed request by calling a seed acquisition function to read the current value from a hardware timer as the seed, returning the seed to the hardware-in-the-loop test platform, and freezing it in local storage; the hardware-in-the-loop test platform calculating the expected key after receiving the seed and sending it to the controller; the controller calculating a comparison key based on the frozen seed, comparing the comparison key with the expected key to obtain the authentication result, and feeding the authentication result back to the hardware-in-the-loop test platform; and the hardware-in-the-loop test platform recording the authentication result, comparing it with the expected value, and generating a test report.

Description

Technical Field

[0001] This application relates to the field of vehicle controller certification, specifically a safety certification test method, system, and vehicle for vehicle controllers. Background Technology

[0002] Secure access mechanisms are crucial for protecting critical functions (such as firmware upgrades, parameter configurations, and diagnostic session switching) in automotive electronic control units (ECUs) from unauthorized operations. In automotive diagnostic protocols, a seed-based secure access scheme is typically employed. The basic process is as follows: the server (ECU) provides a random seed to the client (diagnostic tool). The client calculates a key using the seed and a preset algorithm and sends it back to the server. The server compares its calculated key with the key sent back by the client; if they match, access to the protected functions is granted.

[0003] Currently, the development and deployment of secure access algorithms in automotive ECUs generally follow this process: algorithm designers first write algorithm prototypes in C or MATLAB, manually convert them into C code, and then integrate them into the ECU software. This manual coding method has shortcomings in terms of development efficiency, code consistency, and reliability. Furthermore, existing technologies lack a complete toolchain from algorithm model design to automatic code generation and hardware-in-the-loop (HIL) testing and verification, making it difficult to systematically verify and guarantee the correctness of the algorithm in real controllers. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a safety certification testing method, system, and vehicle for an on-board controller.

[0005] The technical solution of this invention is as follows:

[0006] Firstly, this application provides a safety certification test method for an on-board controller, including:

[0007] A fixed-point simulation model of the key generation algorithm is established in a simulation modeling environment. After the fixed-point simulation model is verified by simulation, the fixed-point simulation model is converted into target code using a code generation tool and burned into the controller under test.

[0008] Place the controller under test on a hardware-in-the-loop test platform;

[0009] The hardware-in-the-loop test platform sends a seed request to the controller under test via a bus.

[0010] In response to the seed request, the controller under test calls the seed acquisition function to read the current value from the hardware timer as the seed, returns the seed to the hardware-in-the-loop test platform and freezes it in the local storage area;

[0011] After receiving the seed, the hardware-in-the-loop test platform calculates the expected key and sends the expected key to the controller under test.

[0012] After receiving the expected key, the controller under test calculates the comparison key based on the frozen seed, compares the comparison key with the expected key to obtain the authentication result, and feeds the authentication result back to the hardware-in-the-loop test platform.

[0013] The hardware-in-the-loop testing platform records the authentication results and compares them with the expected values ​​to generate a test report.

[0014] By modeling the key generation algorithm in a simulation modeling environment and automatically generating target code, and because the simulation modeling model adopts a fixed-point design and the data bit width is completely consistent with the embedded controller hardware, algorithm logic errors can be found during the simulation verification stage without having to wait for the code to be burned before debugging. Therefore, it can eliminate the inefficiency and error introduction problems caused by traditional manual coding.

[0015] Since the model is verified through simulation before the code is generated, and the code generation tool automatically outputs the target code based on the model rather than manually converting it, the consistency between the algorithm model and the embedded code can be guaranteed.

[0016] Throughout the entire testing process, the hardware-in-the-loop testing platform automatically sends seed requests, receives authentication results, and compares them with expected values, eliminating the need for manual evaluation of each test result and thus improving the testing efficiency of vehicle controllers.

[0017] In some possible embodiments, the step of calculating the comparison key based on the frozen seed includes:

[0018] The key calculation function is invoked, and the key generation algorithm is called internally by the key calculation function to calculate the comparison key based on the seed. Specifically, this includes:

[0019] A preset application constant is defined, which is then decomposed into constant bytes equal to the number of bytes of the seed read from the hardware timer.

[0020] Using the seed read from the hardware timer as input, each byte of the seed is XORed with the corresponding byte of the application constant to obtain a first intermediate key component with the same number of bytes as the seed;

[0021] Each of the first intermediate key components is shifted by a different number of bits and then summed to obtain the first key;

[0022] Perform bit mirroring operations on each byte of the seed in reverse order of input to obtain mirrored bytes with the same number of bytes as the seed. Then, combine the mirrored bytes in order to form a second seed. The bit mirroring operation refers to mapping each binary bit of the byte to the corresponding bit of the output byte in reverse order.

[0023] The second seed is decomposed into bytes, and each byte is XORed with the corresponding byte in the constant byte to obtain a second intermediate key component with the same number of bytes as the second seed.

[0024] The second key is obtained by shifting each of the second intermediate key components by different numbers and then summing them.

[0025] Add the first key and the second key, discard any overflow carry, decompose the result into bytes and output it in big-endian order as the key.

[0026] By pre-setting an application constant and decomposing it byte by byte, the first key is obtained by XORing each byte of the seed with the corresponding byte of the application constant and then accumulating them with different bit shifts. At the same time, the second key is obtained by recombining each byte of the seed after bit mirroring and XORing and bit shifting. Finally, the first key and the second key are added together and the overflow carry is discarded before output. This ensures that the same input seed can produce the exact same key output when calculated on the server and client sides, guaranteeing the consistency and reproducibility of the calculation results of both parties during the security authentication process. Since the bit mirroring operation maps each binary bit of the input byte to the corresponding bit of the output byte in reverse order, it increases the non-linearity between the key and the seed, making it difficult for attackers to deduce the key from the seed through simple mathematical relationships. Since the first key and the second key are calculated and summed twice independently based on the original byte of the seed and the bit mirrored byte, the result of any single path operation cannot be directly used as the final key output, further increasing the difficulty of brute-force cracking. Thus, the anti-attack capability of the vehicle controller's secure access authentication is improved without adding an external random number generator.

[0027] In some possible embodiments, the step of comparing the comparison key with the expected key to obtain the authentication result includes:

[0028] The comparison key is compared byte by byte with the expected key;

[0029] If all bytes are consistent, an authentication pass result is generated, and the protected functions of the controller under test are unlocked;

[0030] If any byte is inconsistent, an authentication failure result is generated, the controller under test returns a negative response and accumulates the number of consecutive failures;

[0031] When the number of consecutive failures exceeds a preset threshold, the secure access channel of the controller under test is locked, and the response to the next seed request sent by the test bench is delayed.

[0032] By comparing the comparison key with the expected key byte by byte, authentication is successful and the function is unlocked only if all bytes match. If any byte does not match, authentication fails and the number of consecutive failures is accumulated. This can accurately determine whether the client has the correct key generation algorithm, avoiding the risk of misjudgment due to partial matching. At the same time, by accumulating the number of consecutive failures and locking the secure access channel and delaying the response to the next seed request when the number of consecutive failures exceeds a preset threshold, it can effectively identify and suppress brute-force attempts against the secure access channel, increasing the attacker's time cost. Thus, without changing the complexity of the key generation algorithm itself, the anti-attack capability of the vehicle controller's secure access authentication is improved through strategic delay and locking mechanisms.

[0033] In some possible embodiments, the expected key is calculated by the hardware-in-the-loop test platform based on the received seed, using the same reference model as the fixed-point simulation model.

[0034] Because the hardware-in-the-loop test platform uses the same reference model as the fixed-point simulation model to calculate the expected key, this reference model is mathematically and logically identical to the algorithm model corresponding to the C code burned into the controller under test (DUT). This ensures that the same input seed yields the same key output when calculated on both the hardware-in-the-loop test platform and the DUT, thus guaranteeing that the authentication results fed back by the DUT have a predictable and correct reference benchmark. Furthermore, since the hardware-in-the-loop test platform does not rely on any intermediate calculation results from the DUT when calculating the expected key, but instead independently completes the key calculation before sending it to the DUT for comparison, the stimulus input and verification output during the test process are independent. This avoids the risk of test failure caused by directly using the DUT's calculation results as the judgment basis, thereby improving the reliability and effectiveness of the hardware-in-the-loop test.

[0035] In some possible embodiments, the method further includes:

[0036] When the controller under test receives a seed request or expected key carrying a bit flip or CRC error from the hardware-in-the-loop test platform, it performs error detection on the data frame that has a bit flip or CRC error.

[0037] If a bit flip or CRC error is detected, the controller under test discards the current data frame, returns a negative response code to the hardware-in-the-loop test platform, and maintains the current secure access state.

[0038] By sending a seed request or expected key carrying bit flips or CRC errors to the controller under test (DUT) during the hardware-in-the-loop testing phase, the DUT's error detection capability enables it to identify bit errors or checksum errors occurring during physical transmission at the data frame level. This verifies the DUT's ability to identify damaged data frames in a real bus communication environment. When an error is detected, the DUT discards the current data frame and returns a negative response code while maintaining the current secure access state. This avoids the risk of abnormal state machine transitions or misinterpretations due to erroneous data, and prevents the entire secure access channel from being locked due to a single communication error. It ensures that subsequent correct requests can still be responded to normally, thus verifying that the DUT can correctly distinguish between data corruption and authentication failure in communication anomaly scenarios, and can maintain the correct recovery capability of the state machine without affecting subsequent normal communication.

[0039] In some possible embodiments, the method further includes:

[0040] When the hardware-in-the-loop test platform detects that there are frame losses or out-of-order data frames sent by the hardware-in-the-loop test platform, the controller under test starts a timeout countdown.

[0041] If a correctly formatted data frame is not received within the preset timeout period, the controller under test returns to the state of waiting for the next seed request.

[0042] By simulating data frame loss or out-of-order delivery using a hardware-in-the-loop test platform, the controller under test (DUT) initiates a timeout upon detecting a communication anomaly. If a correctly formatted data frame is not received within the preset timeout period, the DUT proactively reverts to a state of waiting for the next seed request. This verifies that the DUT possesses timeout detection and autonomous recovery capabilities under bus communication anomaly scenarios, preventing it from being permanently suspended due to waiting for data frames that will never arrive. Furthermore, since the frozen seeds in the internal buffer are cleared after state recovery, the next secure access session will not be confused with the data from the previous incomplete session. This ensures that the secure access state machine can restart the authentication process in a clean state after anomaly recovery, avoiding authentication logic errors or security vulnerabilities caused by historical residual data.

[0043] In some possible embodiments, the controller under test receives the seed request and expected key sent by the hardware-in-the-loop test platform via the UDS protocol, and returns a response to the hardware-in-the-loop test platform via the UDS protocol.

[0044] The controller under test (DUT) receives the seed request and expected key sent by the hardware-in-the-loop test platform via the UDS protocol and returns a response via the same protocol. Since the UDS protocol is a common diagnostic communication standard in the automotive electronics field, the hardware-in-the-loop test platform also supports this protocol. This ensures that the communication method of the DUT in the hardware-in-the-loop test environment is completely consistent with its communication method in the real vehicle environment, verifying the correctness of the security authentication algorithm under the actual vehicle diagnostic communication protocol stack. At the same time, since the UDS protocol specifies that the seed request and key request correspond to different sub-functions of the 0x27 service, the DUT parses the request and returns a response according to the protocol, ensuring that the security authentication process conforms to the standard interaction specifications of the vehicle network. This allows the test results to directly reflect the secure access behavior of the DUT in the real vehicle environment.

[0045] In some possible embodiments, the seed acquisition function reads the current count value of the free-running timer from a preset hardware address as the seed, wherein the seed is an unsigned integer value of a preset byte length.

[0046] The seed acquisition function reads the current count value of the free-running timer from a preset hardware address as the seed. Since the free-running timer runs independently and continuously after the controller under test is powered on, its count value increases over time and is not controlled by the software flow, making each seed value unique and unpredictable. At the same time, since the seed is a 32-bit unsigned integer value with a range of 2 to the power of 32, the seed values ​​read from two adjacent times do not show a fixed correlation in value. This ensures that the seed used in each session during secure access has sufficient randomness, avoiding the risk of replay attacks due to predictable seeds. Furthermore, since the seed comes directly from the hardware register rather than being generated by a software algorithm, no additional random number generator or seed update logic is needed, reducing code complexity and runtime overhead.

[0047] Secondly, this application provides a security authentication test system for an on-board controller, including a hardware-in-the-loop test platform and a controller under test. A fixed-point simulation model of a key generation algorithm is established in a simulation modeling environment. After the fixed-point simulation model is simulated and verified, the fixed-point simulation model is converted into target code using a code generation tool and burned into the controller under test.

[0048] Place the controller under test on a hardware-in-the-loop test platform;

[0049] The hardware-in-the-loop test platform sends a seed request to the controller under test via a bus.

[0050] In response to the seed request, the controller under test calls the seed acquisition function to read the current value from the hardware timer as the seed, returns the seed to the hardware-in-the-loop test platform and freezes it in the local storage area;

[0051] After receiving the seed, the hardware-in-the-loop test platform calculates the expected key and sends the expected key to the controller under test;

[0052] After receiving the expected key, the controller under test calculates the comparison key based on the frozen seed, compares the comparison key with the expected key to obtain the authentication result, and feeds the authentication result back to the hardware-in-the-loop test platform.

[0053] The hardware-in-the-loop testing platform records the authentication results and compares them with the expected values ​​to generate a test report.

[0054] Thirdly, this application provides a vehicle equipped with an on-board controller, which is manufactured after passing the aforementioned safety certification test method for on-board controllers. Attached Figure Description

[0055] Figure 1 This is a flowchart illustrating the security certification test method for the vehicle controller in this application embodiment;

[0056] Figure 2 This is a structural block diagram of the vehicle controller safety certification test system in the embodiments of this application. Detailed Implementation

[0057] Reference Figure 1 This application provides a security certification test method for an on-board controller, including:

[0058] S101, establish a fixed-point simulation model of the key generation algorithm in the simulation modeling environment, and after simulating and verifying the fixed-point simulation model, use a code generation tool to convert the fixed-point simulation model into target code and burn it into the controller under test 200.

[0059] S102, Place the controller under test 200 on the hardware-in-the-loop test platform 100;

[0060] S103, the hardware-in-the-loop test platform 100 sends a seed request to the controller under test 200 via the bus;

[0061] S104, the controller under test 200 responds to the seed request by calling the seed acquisition function to read the current value from the hardware timer as the seed, and returns the seed to the hardware-in-the-loop test platform 100 and freezes it in the local storage area;

[0062] S105, after receiving the seed, the hardware-in-the-loop test platform 100 calculates the expected key and sends the expected key to the controller under test 200;

[0063] S106 After receiving the expected key, the controller under test 200 calculates the comparison key based on the frozen seed, compares the comparison key with the expected key to obtain the authentication result, and feeds the authentication result back to the hardware-in-the-loop test platform 100.

[0064] S107, the hardware-in-the-loop test platform 100 records the certification results and compares them with the expected values ​​to generate a test report.

[0065] In step S101, the simulation modeling environment in this embodiment refers to the Simulink environment. When establishing a fixed-point simulation model of the key generation algorithm in the Simulink environment, the corresponding computation module is built in the Simulink model according to the mathematical definition of the key generation algorithm. The model adopts a fixed-point design, and the data bit width is strictly configured as 8-bit, 16-bit, and 32-bit unsigned integers, consistent with the hardware word length of the controller under test 200. The model comprises the following subsystems: a seed input subsystem for receiving a 4-byte seed and splitting it into a byte stream; a constant storage subsystem for pre-setting a 32-bit application constant 0x75E47D24 and decomposing it by bytes; a first XOR and bitwise increment subsystem for performing an XOR operation on each byte of the seed with the corresponding byte of the constant and then incrementing it by bitwise increment to obtain the first key; a bitwise mirror lookup table subsystem for using a Lookup Table module to implement fixed bitwise mirror mapping to avoid iterative loops; a second XOR and bitwise increment subsystem for performing an XOR operation and bitwise increment on the bitwise mirrored seed to obtain the second key; an adder and carry discarding subsystem for adding the first key and the second key and discarding any overflow carry; and a key reconstruction subsystem for decomposing the addition result by bytes and outputting it in big-endian order.

[0066] The model was run in the Simulink environment in Normal, Accelerator, and Rapid Accelerator simulation modes respectively. The fixed-point operation output of each subsystem was compared byte by byte with the output of the pure C reference code to verify that the behavior of the model in each simulation mode was completely consistent with the reference code, thus ensuring the correctness of the fixed-point operation behavior.

[0067] After the simulation verification is successful, configure the parameters of the Simulink code generation tool, select the corresponding code replacement library for the target controller chip, so that the generated C code (i.e. the target code) can call the optimized instructions of the target chip; at the same time, configure the memory segment, store constants in the read-only data segment, and allocate intermediate variables in the stack or static storage area; finally, call SimulinkCoder or Embedded Coder to generate ANSI C code.

[0068] The generated C code is compiled using the compiler corresponding to the target chip, and the resulting executable file is then burned into the non-volatile memory of the controller under test 200.

[0069] In this embodiment of the application, the key generation algorithm is defined as follows:

[0070] It takes a seed of a preset byte length as input and a key of the same byte length as output;

[0071] A preset application constant is defined, which is then decomposed into constant bytes equal to the number of bytes of the seed read from the hardware timer.

[0072] Using the seed read from the hardware timer as input, each byte of the seed is XORed with the corresponding byte of the application constant to obtain a first intermediate key component with the same number of bytes as the seed;

[0073] Each of the first intermediate key components is shifted by a different number of bits and then summed to obtain the first key;

[0074] Perform bit mirroring operations on each byte of the seed in reverse order of input to obtain mirrored bytes with the same number of bytes as the seed. Then, combine the mirrored bytes in order to form a second seed. The bit mirroring operation refers to mapping each binary bit of the byte to the corresponding bit of the output byte in reverse order.

[0075] The second seed is decomposed into bytes, and each byte is XORed with the corresponding byte in the constant byte to obtain a second intermediate key component with the same number of bytes as the second seed.

[0076] The second key is obtained by shifting each of the second intermediate key components by different numbers and then summing them.

[0077] Add the first key and the second key, discard any overflow carry, decompose the result into bytes and output it in big-endian order as the key.

[0078] In a specific example of this application, a 4-byte seed is used as input and a 4-byte key is used as output. A 32-bit application constant is preset, typically 0x75E47D24, which is decomposed into 4 bytes. The specific process of the key generation algorithm includes:

[0079] Perform an XOR operation between each byte of the 4-byte seed and the corresponding byte of the application constant to obtain four first intermediate key components. Shift the first first intermediate key component left by 24 bits, the second by 16 bits, the third by 8 bits, and leave the fourth unchanged. Sum the four shifted components to obtain a 32-bit first key.

[0080] Perform a bit-mirroring operation on each byte of the seed. Bit-mirroring means mapping bits 0 to 7 of the input byte to bits 7 to 0 of the output byte in reverse order. After bit-mirroring the 3rd, 2nd, 1st, and 0th bytes of the seed, four mirrored bytes are obtained, which are then combined in sequence to form a 32-bit second seed. The second seed is decomposed into four bytes, and each is XORed with the corresponding byte with the applied constant to obtain four second intermediate key components. The first second intermediate key component is left-shifted by 24 bits, the second by 16 bits, the third by 8 bits, and the fourth remains unchanged. The four shifted components are then summed to obtain the 32-bit second key.

[0081] Add the first key to the second key, discard any overflow carry, decompose the result into bytes and output it in big-endian order as a 4-byte key.

[0082] By pre-setting a 32-bit application constant and decomposing it byte by byte, the first key is obtained by XORing each byte of the seed with the corresponding byte of the application constant and then accumulating them with different bit shifts. At the same time, the second key is obtained by recombining each byte of the seed after bit mirroring and XORing and bit shifting. Finally, the first key and the second key are added together and the overflow carry is discarded before output. This ensures that the same input seed can produce the exact same 4-byte key output when calculated on the server and client sides, guaranteeing the consistency and reproducibility of the calculation results of both parties during the security authentication process. Since the bit mirroring operation maps the 0th to 7th bits of the input byte to the 7th to 0th bits of the output byte in reverse order, it increases the non-linearity between the key and the seed, making it difficult for attackers to deduce the key from the seed through simple mathematical relationships. Since the first key and the second key are calculated and summed twice independently based on the original seed byte and the bit mirrored byte, the result of any single path operation cannot be directly used as the final key output, further increasing the difficulty of brute-force cracking. Thus, the anti-attack capability of the vehicle controller's secure access authentication is improved without adding an external random number generator.

[0083] Reference Figure 2 The vehicle controller safety certification test system includes a hardware-in-the-loop test platform 100 and a controller under test 200; the hardware-in-the-loop test platform 100 includes a host computer 101, a real-time simulator 102 and a bus interface card 103.

[0084] The host computer 101 and the real-time emulator 102 are connected via Ethernet. The host computer 101 runs test scripts and sends control commands to the real-time emulator 102 via Ethernet. The real-time emulator 102 is connected to the bus interface card 103 via a backplane bus or a high-speed data interface. The bus interface card 103 is directly connected to the controller under test 200 via a CAN, CAN FD, or Ethernet bus harness.

[0085] After the controller under test (DUT) 200 is connected to the bus interface card 103 of the hardware-in-the-loop test platform 100 via a bus, the test script in the host computer 101 controls the real-time emulator 102 to initiate a secure access test sequence. The real-time emulator 102 sends a seed request message in UDS protocol format to the DUT 200 through the bus interface card 103. The DUT 200 responds to the request and returns the seed. After receiving the seed, the real-time emulator 102 passes it to the host computer 101. The host computer 101 calls the reference model to calculate the expected key and sends it back to the real-time emulator 102. The real-time emulator 102 then sends the expected key to the DUT 200 through the bus interface card 103. After verification, the DUT 200 feeds back the authentication result. Finally, the host computer 101 records and compares the results to generate a test report. The host computer 101, the real-time emulator 102, and the bus interface card 103 work together to realize a complete test closed loop from stimulus transmission, data interaction, key calculation to result determination.

[0086] In step S103, the test script in the host computer 101 initiates the test sequence and sends an instruction to the real-time emulator 102. The instruction is "send a diagnostic message requesting a seed (UDS 0x27 01) to the controller under test (DUT) 200". After receiving the instruction from the host computer 101, the real-time emulator 102 transmits the seed request message data to be sent to the bus interface card 103. The bus interface card 103 encapsulates the message data into a physical layer signal according to the CAN, CAN FD, or Ethernet protocol and sends it to the DUT 200 through the bus harness. The entire seed request sending process is initiated by the test script in the host computer 101, forwarded by the real-time emulator 102, physically transmitted by the bus interface card 103, and finally received by the DUT 200.

[0087] In step S103, after the bus interface hardware of the controller under test 200 receives the seed request data frame, it notifies the CPU via a hardware interrupt. The driver in the CPU then passes the data frame to the UDS diagnostic stack. The diagnostic stack parses the request as a secure access seed request for the UDS0x27 service and then calls the seed acquisition function GetSeed.

[0088] The seed acquisition function reads the current count value of the free-running timer from the preset hardware address 0xFFBF7010UL. This timer runs independently after the controller under test 200 is powered on. The value read is the seed, which is a 32-bit unsigned integer value.

[0089] The controller under test 200 encapsulates the read seed value into a UDS response message and sends it back to the bus interface card 103 of the hardware-in-the-loop test platform 100 through the bus interface hardware of the controller under test 200. After receiving the response message, the bus interface card 103 passes it to the real-time simulator 102, and the real-time simulator 102 then passes it back to the host computer 101.

[0090] Seed freezing refers to the process where the controller under test (DUT) 200, while sending the seed back to the hardware-in-the-loop test platform 100, saves a copy of the seed to its internal RAM buffer and marks the buffer as filled. The purpose of freezing is to ensure that the seed value is not overwritten or changed by any subsequent operations during the entire period of waiting for the client to return the key, thus enabling the correct comparison key to be calculated using the same original seed during subsequent key verification. The freezing operation is managed by the secure access state machine within the DUT 200, executed after successful seed transmission, and unfrozen and the buffer cleared after key verification is completed or the session times out.

[0091] In step S104, the controller under test 200 encapsulates the seed into a UDS response message and sends it back via the bus. The bus interface card 103 of the hardware-in-the-loop test platform 100 receives the message and passes it to the real-time simulator 102. The real-time simulator 102 extracts the seed value and then transmits the seed value to the host computer 101 via Ethernet.

[0092] A test script runs on the host computer 101. Upon receiving a seed value, the test script calls a key generation algorithm reference model identical to the fixed-point simulation model. This reference model exists in two forms: a Simulink reference model and an independent C function library. For the Simulink reference model, the MATLAB / Simulink environment on the host computer 101 loads a key generation algorithm model with the same source code as the C code in the controller under test 200. The received seed value is used as the model input, and the desired key is obtained from the model's output port after simulation. For the independent C function library, the host computer 101 contains a compiled independent C function library with the same algorithm logic as the C code in the controller under test 200. The test script calls the key calculation function in this library, passing in the seed value. The function executes the complete key generation algorithm and returns the desired key.

[0093] After receiving the seed, the reference model or C function library executes the complete key generation algorithm: First, a 32-bit application constant is preset and decomposed byte-wise. Each byte of the 4-byte seed is XORed with the corresponding byte of the application constant to obtain four first intermediate key components. These are then accumulated after different bit shifts to obtain a 32-bit first key. Next, each byte of the 4-byte seed is bit-mirrored and reassembled into a 32-bit second seed. This is decomposed into four bytes and XORed with the corresponding byte of the application constant to obtain four second intermediate key components. These are then accumulated after different bit shifts to obtain a 32-bit second key. Finally, the first and second keys are added together, discarding any carry. The result is then decomposed byte-wise and output in big-endian order to obtain the 4-byte desired key.

[0094] The host computer 101 transmits the calculated expected key back to the real-time emulator 102 via Ethernet. The real-time emulator 102 encapsulates the expected key into a key request message in UDS protocol format and transmits it to the bus interface card 103. The bus interface card 103 then sends the message to the controller under test 200 via the bus.

[0095] In step S105, after the bus interface hardware of the controller under test 200 receives the expected key data frame sent by the hardware-in-the-loop test platform 100, it notifies the CPU through a hardware interrupt. The driver in the CPU passes the data frame to the UDS diagnostic stack. The diagnostic stack parses the request as a send key request for the UDS 0x27 service and extracts the expected key value from it.

[0096] The controller under test (DUT) 200 calls the key calculation function `CalculateKey`, taking the seed frozen in the internal buffer as input, and executes the key generation algorithm to calculate the comparison key. The execution process of the key calculation function is as follows: First, a 32-bit application constant is preset and decomposed into four bytes. Each byte of the frozen 4-byte seed is XORed with the corresponding byte of the application constant to obtain four first intermediate key components. These are then accumulated after different bit shifts to obtain a 32-bit first key. Next, each byte of the frozen 4-byte seed is bit-mirrored, and the resulting bytes are reassembled into a 32-bit second seed. This seed is then decomposed into four bytes and XORed with the corresponding byte of the application constant to obtain four second intermediate key components. These are then accumulated after different bit shifts to obtain a 32-bit second key. Finally, the first key and the second key are added together, discarding any overflow carry. The result is then decomposed into bytes and output in big-endian order to obtain a 4-byte comparison key.

[0097] The controller under test 200 calls the key verification function VerifyKey to compare the calculated comparison key with the expected key sent by the hardware-in-the-loop test platform 100 byte by byte. The comparison process starts from the 0th byte of the two keys and compares them sequentially to the 3rd byte. If all four bytes are the same, they are considered to be consistent; if any byte is different, they are considered to be inconsistent.

[0098] If the key being compared matches the expected key in all bytes, the key verification function returns an authentication success result, and the controller under test 200 unlocks the protected functions.

[0099] If any byte of the comparison key is inconsistent with the expected key, the key verification function returns an authentication failure result, the controller under test 200 returns a negative response code, and the number of consecutive failures is accumulated.

[0100] The authentication result is encapsulated into a UDS response message and sent back to the bus interface card 103 of the hardware-in-the-loop test platform 100 via the bus interface hardware. After receiving the message, the bus interface card 103 passes it to the real-time emulator 102, which then passes it back to the host computer 101. The host computer 101 records the result and compares it with the expected value.

[0101] In step S106, the controller under test 200 encapsulates the authentication result into a UDS response message and sends it back via the bus. The bus interface card 103 of the hardware-in-the-loop test platform 100 receives the message and passes it to the real-time simulator 102. The real-time simulator 102 extracts the authentication result (authentication passed or authentication failed) and then transmits the authentication result back to the host computer 101 via Ethernet.

[0102] After receiving the authentication result, the test script in the host computer 101 records all the data of this test case to local storage. The recorded data includes at least: the test case number, the seed value sent, the seed value returned by the controller under test 200, the expected key value calculated by the host computer 101, the authentication result fed back by the controller under test 200, the expected value of this test, and the timestamp corresponding to each step of the operation.

[0103] The test script compares the actual authentication result returned by the controller under test 200 with the preset expected value. If the actual authentication result matches the expected value, the test case is deemed to have passed; otherwise, it is deemed to have failed. For exception injection test cases, the expected value is a negative response code or a specific error behavior. The test script also compares the negative response code or status behavior returned by the controller under test 200 with the expected value to determine whether the exception handling meets expectations.

[0104] After all test cases have been executed, the host computer 101 summarizes all test records and comparison results, and automatically generates a test report. The test report includes at least: test environment information, input and output data for each test case, comparison conclusions between actual and expected results, pass / fail flags, and records of error handling behavior of the controller under test 200 in exception injection scenarios. The test report is used to evaluate the correctness and robustness of the security authentication algorithm in the controller under test 200, and serves as a regression comparison basis after algorithm model updates or code regeneration.

[0105] In some possible embodiments, the method further includes:

[0106] When the controller under test 200 receives a seed request or expected key carrying a bit flip or CRC error from the hardware-in-the-loop test platform 100, it performs error detection on the data frame that has a bit flip or CRC error.

[0107] If a bit flip or CRC error is detected, the controller under test 202 discards the current data frame, returns a negative response code to the hardware-in-the-loop test platform 100, and maintains the current secure access state unchanged.

[0108] By sending a seed request or expected key carrying bit flips or CRC errors to the controller under test 200 during the hardware-in-the-loop testing phase, the controller under test 200, with its error detection capability, can identify bit errors or check errors occurring during physical transmission at the data frame level. This verifies the controller under test's ability to identify damaged data frames in a real bus communication environment. When an error is detected, the controller under test 200 discards the current data frame and returns a negative response code, while maintaining the current secure access state. This avoids the risk of abnormal state machine transitions or misinterpretations due to erroneous data, and prevents the entire secure access channel from being locked due to a single communication error. It ensures that subsequent correct requests can still be responded to normally, thus verifying that the controller under test 200 can correctly distinguish between data corruption and authentication failure in communication anomaly scenarios, and can maintain the correct recovery capability of the state machine without affecting subsequent normal communication.

[0109] In some possible embodiments, the method further includes:

[0110] When the hardware-in-the-loop test platform 100 detects that there are frame loss or out-of-order data frames sent by the hardware-in-the-loop test platform 100, the controller under test 200 starts a timeout countdown.

[0111] If a correctly formatted data frame is not received within the preset timeout period, the controller under test 200 returns to the state of waiting for the next seed request.

[0112] By simulating data frame loss or out-of-order delivery using a hardware-in-the-loop test platform 100, the controller under test 200 starts a timeout after recognizing the communication anomaly. If a correctly formatted data frame is not received within the preset timeout period, it actively recovers to the state of waiting for the next seed request. This verifies that the controller under test 200 has the ability to detect timeouts and recover autonomously in bus communication anomaly scenarios, and will not be permanently suspended due to waiting for data frames that will never arrive. On the other hand, since the frozen seeds in the internal buffer are cleared after the state is restored, the next secure access session will not cause data confusion with the previous incomplete session. This ensures that the secure access state machine can restart the authentication process in a clean state after the anomaly is recovered, avoiding authentication logic errors or security vulnerabilities caused by historical residual data.

[0113] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims. Those skilled in the art can understand that implementing all or part of the processes of the above embodiments and making equivalent changes according to the claims of this application still fall within the scope of this application.

Claims

1. A safety certification test method for an on-board controller, characterized in that, include: A fixed-point simulation model of the key generation algorithm is established in a simulation modeling environment. After the fixed-point simulation model is verified by simulation, the fixed-point simulation model is converted into target code using a code generation tool and burned into the controller under test. Place the controller under test on a hardware-in-the-loop test platform; The hardware-in-the-loop test platform sends a seed request to the controller under test via a bus. In response to the seed request, the controller under test calls the seed acquisition function to read the current value from the hardware timer as the seed, returns the seed to the hardware-in-the-loop test platform and freezes it in the local storage area; After receiving the seed, the hardware-in-the-loop test platform calculates the expected key and sends the expected key to the controller under test. After receiving the expected key, the controller under test calculates the comparison key based on the frozen seed, compares the comparison key with the expected key to obtain the authentication result, and feeds the authentication result back to the hardware-in-the-loop test platform. The hardware-in-the-loop testing platform records the authentication results and compares them with the expected values ​​to generate a test report.

2. The method according to claim 1, characterized in that, The steps for calculating the comparison key based on the frozen seed include: The key calculation function is invoked, and the key generation algorithm is called internally by the key calculation function to calculate the comparison key based on the seed. Specifically, this includes: A preset application constant is defined, which is then decomposed into constant bytes equal to the number of bytes of the seed read from the hardware timer. Using the seed read from the hardware timer as input, each byte of the seed is XORed with the corresponding byte of the application constant to obtain a first intermediate key component with the same number of bytes as the seed; Each of the first intermediate key components is shifted by a different number of bits and then summed to obtain the first key; Perform bit mirroring operations on each byte of the seed in reverse order of input to obtain mirrored bytes of the same number as the seed bytes. Then, combine the mirrored bytes in order to form a second seed. The bit mirroring operation refers to mapping each binary bit of the byte to the corresponding bit of the output byte in reverse order. The second seed is decomposed into bytes, and each byte is XORed with the corresponding byte in the constant byte to obtain a second intermediate key component with the same number of bytes as the second seed. The second key is obtained by shifting each of the second intermediate key components by different numbers and then summing them. Add the first key and the second key, discard any overflow carry, decompose the result into bytes and output it in big-endian order as the key.

3. The method according to claim 1, characterized in that, The step of comparing the comparison key with the expected key to obtain the authentication result includes: The comparison key is compared byte by byte with the expected key; If all bytes are consistent, an authentication pass result is generated, and the protected functions of the controller under test are unlocked; If any byte is inconsistent, an authentication failure result is generated, the controller under test returns a negative response and accumulates the number of consecutive failures; When the number of consecutive failures exceeds a preset threshold, the secure access channel of the controller under test is locked, and the response to the next seed request sent by the test bench is delayed.

4. The method according to claim 1, characterized in that, The expected key is calculated by the hardware-in-the-loop test platform based on the received seed, using a reference model identical to the fixed-point simulation model.

5. The method according to claim 1, characterized in that, The method further includes: When the controller under test receives a seed request or expected key carrying a bit flip or CRC error from the hardware-in-the-loop test platform, it performs error detection on the data frame that has a bit flip or CRC error. If a bit flip or CRC error is detected, the controller under test discards the current data frame, returns a negative response code to the hardware-in-the-loop test platform, and maintains the current secure access state.

6. The method according to claim 1, characterized in that, The method further includes: When the hardware-in-the-loop test platform detects that there are frame losses or out-of-order data frames sent by the hardware-in-the-loop test platform, the controller under test starts a timeout countdown. If a correctly formatted data frame is not received within the preset timeout period, the controller under test returns to the state of waiting for the next seed request.

7. The method according to claim 1, characterized in that, The controller under test receives the seed request and expected key sent by the hardware-in-the-loop test platform via the UDS protocol, and returns a response to the hardware-in-the-loop test platform via the UDS protocol.

8. The method according to claim 1, characterized in that, The seed acquisition function reads the current count value of the free-running timer from a preset hardware address as the seed, and the seed is an unsigned integer value of a preset byte length.

9. A safety certification testing system for an on-board controller, characterized in that, The system includes a hardware-in-the-loop test platform and a controller under test. A fixed-point simulation model of the key generation algorithm is established in a simulation modeling environment. After the fixed-point simulation model is verified by simulation, the fixed-point simulation model is converted into target code using a code generation tool and burned into the controller under test. Place the controller under test on a hardware-in-the-loop test platform; The hardware-in-the-loop test platform sends a seed request to the controller under test via a bus. In response to the seed request, the controller under test calls the seed acquisition function to read the current value from the hardware timer as the seed, returns the seed to the hardware-in-the-loop test platform and freezes it in the local storage area; After receiving the seed, the hardware-in-the-loop test platform calculates the expected key and sends the expected key to the controller under test. After receiving the expected key, the controller under test calculates the comparison key based on the frozen seed, compares the comparison key with the expected key to obtain the authentication result, and feeds the authentication result back to the hardware-in-the-loop test platform. The hardware-in-the-loop testing platform records the authentication results and compares them with the expected values ​​to generate a test report.

10. A vehicle, characterized in that, The vehicle is equipped with an on-board controller, which is manufactured after passing the safety certification test method for an on-board controller according to any one of claims 1-8.

Images