Signature verification method and device, equipment and storage medium

Abstract

The invention discloses a signature verification method and device, equipment and a storage medium, and relates to the technical field of vehicle software upgrading. The method is executed by a vehicle ECU (Electronic Control Unit) and comprises the following steps of: splitting signature information, a public key index and a public key modulus under the condition of receiving a data packet sent by a vehicle diagnostic instrument; the data packet contains signature information; the split signature information and the split public key index are converted to a Montgomery domain; performing accumulation calculation on the split signature information in the Montgomery form and the split public key index in the Montgomery form through an accumulator to obtain an intermediate calculation item; through Montgomery reduction, based on the intermediate calculation item and the split public key modulus, obtaining a hash value for analyzing the data packet; and under the condition that the hash value of the data packet is consistent with the hash value for analyzing the data packet, judging that the signature information is successfully verified. According to the application, verification of the signature can be realized under the condition that the computing power of the vehicle ECU and the RAM space are limited.

Description

Technical Field

[0001] This application relates to the field of vehicle software upgrade technology, and in particular to a signature verification method, apparatus, device, and storage medium. Background Technology

[0002] To address cybersecurity risks arising from the trends of intelligentization and connectivity, the automotive industry is placing higher demands on vehicle software upgrades and cybersecurity.

[0003] In related technologies, the sender (such as an OTA server) can first calculate the hash value of the data packet to be transmitted, and then encrypt the hash value using an RSA private key to generate a digital signature. Correspondingly, the receiver (vehicle ECU) decrypts the digital signature using an RSA public key. If the signature information is successfully verified, it means that the received data packet has not been tampered with during transmission.

[0004] However, the RSA algorithm has high computational overhead and high storage requirements. Small vehicle ECUs, due to their low microcontroller computing power and limited RAM space, find it difficult to run the RSA algorithm smoothly. Summary of the Invention

[0005] This application provides a signature verification method, apparatus, device, and storage medium, which can verify RSA signatures even when the computing power and RAM space of a vehicle ECU are limited. The technical solution is as follows:

[0006] According to one aspect of the embodiments of this application, a signature verification method is provided, the method being executed by a vehicle electronic control unit (ECU), the method comprising:

[0007] Upon receiving a data packet from the vehicle diagnostic tool, the signature information, public key exponent, and public key modulus are split; the data packet contains the signature information.

[0008] The split signature information and the split public key index are transformed into the Montgomery field to obtain the split signature information and the split public key index in Montgomery form;

[0009] The intermediate calculation term is obtained by performing an accumulation calculation on the signature information after the Montgomery form is split and the public key index after the Montgomery form is split by the accumulator.

[0010] The hash value for parsing the data packet is obtained by Montgomery reduction, based on the intermediate computational term and the modulus of the split public key;

[0011] If the hash value of the data packet matches the hash value obtained by parsing the data packet, the signature information is deemed to have been successfully verified.

[0012] According to one aspect of the embodiments of this application, a signature verification apparatus is provided, the apparatus comprising:

[0013] The data splitting module is used to split the signature information, public key exponent, and public key modulus upon receiving a data packet from a vehicle diagnostic tool; the data packet contains the signature information.

[0014] The data transformation module is used to transform the split signature information and the split public key index to the Montgomery field to obtain the split signature information and the split public key index in Montgomery form.

[0015] The data accumulation module is used to perform accumulation calculations on the signature information after splitting in Montgomery form and the public key index after splitting in Montgomery form through an accumulator to obtain intermediate calculation items;

[0016] The data calculation module is used to obtain the hash value of the parsed data packet by Montgomery reduction, based on the intermediate calculation item and the modulus of the split public key;

[0017] The signature verification module is used to determine that the signature information has been successfully verified if the hash value of the data packet matches the hash value parsed from the data packet.

[0018] In some embodiments, the data calculation module is used to obtain the reduction parameter according to a first formula; the first formula is:

[0019] q = (acc[0] × μ) mod R;

[0020] Where q is the reduction parameter, acc[0] is the least significant block of the accumulator, μ is the modulo inverse constant, and R is the preselection constant;

[0021] The hash value of the parsed data packet is calculated according to the second formula; the second formula is:

[0022]

[0023] Where T' is the hash value parsed from the data packet, T is the intermediate calculation term, q is the reduction parameter, and n is the modulus of the split public key.

[0024] In some embodiments, the signature verification device further includes: a first invocation module, configured to invoke the modulo inverse constant from a non-volatile memory before obtaining the reduction parameter according to the first formula.

[0025] In some embodiments, the signature verification device further includes: a second calling module, configured to call the Montgomery constant from a non-volatile memory before transforming the split signature information and the public key exponent into the Montgomery field to obtain the split signature information and the public key exponent in Montgomery form;

[0026] The data transformation module is used to transform the split signature information and the split public key exponent to the Montgomery field based on the Montgomery constant, so as to obtain the split signature information and the split public key exponent in Montgomery form.

[0027] In some embodiments, the data packet includes at least two data packet blocks; the signature verification device further includes: a data writing module, configured to write the at least two data packet blocks into a non-volatile memory; in the event that the writing of the first data packet block fails, send a retransmission request to the vehicle diagnostic tool; the retransmission request carries identification information of the first data packet block, and the retransmission request is used to instruct the vehicle diagnostic tool to send the first data packet block to the vehicle ECU; receive the first data packet block returned by the vehicle diagnostic tool; and write the first data packet block into the non-volatile memory.

[0028] In some embodiments, the vehicle ECU includes at least one of the following:

[0029] Electric oil pump ECU, electronic water pump ECU, seat ECU, air conditioning ECU.

[0030] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described signature verification method.

[0031] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described signature verification method.

[0032] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described signature verification method.

[0033] The technical solution provided in this application can bring the following beneficial effects:

[0034] When the vehicle ECU receives a data packet from the vehicle diagnostic tool, it can split the signature information, public key index, and public key modulus contained in the data packet into multiple signature information blocks, public key index blocks, and public key modulus blocks. These blocks are then converted to Montgomery form, and an accumulator is used to obtain the intermediate calculation term between the signature information and the public key index. Montgomery reduction is then applied, and based on the intermediate calculation term and the public key modulus block, a hash value for parsing the data packet is obtained. If the hash value for parsing the data packet matches the hash value of the data packet, the vehicle ECU can determine that the signature verification is successful. This solution, by splitting the signature information, public key index, and public key modulus, can break down large integer operations in the signature verification process into multiple blocks, reducing the computational load per data processing step and thus reducing RAM usage. This allows for signature verification even when the vehicle ECU's computing power and RAM space are limited. Attached Figure Description

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

[0036] Figure 1 This is a schematic diagram of an implementation environment provided by an exemplary embodiment of this application;

[0037] Figure 2 This is a flowchart of a signature verification method provided in an exemplary embodiment of this application;

[0038] Figure 3 This is a flowchart of an exemplary embodiment of the electric oil pump RSA signature verification method provided in this application;

[0039] Figure 4 This is a block diagram of a signature verification apparatus provided in an exemplary embodiment of this application;

[0040] Figure 5 This is a structural block diagram of a computer device provided in one embodiment of this application.

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0044] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0045] In this application embodiment, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0046] It should be understood that although the terms first, second, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, a first formula may also be referred to as a second formula, and similarly, a second formula may also be referred to as a first formula. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0047] Please refer to Figure 1 This diagram illustrates an implementation environment provided by an exemplary embodiment of this application. Figure 1 As shown, the implementation environment may include: vehicle 110, server 120, and vehicle diagnostic tool 130.

[0048] The Electronic Control Unit (ECU), also known as the "vehicle computer" or "on-board computer," is an embedded system in the vehicle's electronic system that controls the electronic and electrical systems and automotive subsystems. It is the brain of the vehicle and supports remote diagnostics and over-the-air (OTA) upgrades.

[0049] Vehicle 110 and server 120 communicate with each other via a network. Optionally, vehicle 110 and server 120 may be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0050] Server 120 is used to provide backend services for vehicles 110. Optionally, server 120 is a single server, a server cluster or distributed system consisting of multiple servers, a cloud computing service center, or a cloud server, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, or content delivery network (CDN) that provides cloud computing services. Optionally, server 120 can provide backend services for multiple vehicles 110 simultaneously.

[0051] Vehicle 110 and vehicle diagnostic tool 130 can be connected via wired or wireless communication. For example, the interface of vehicle diagnostic tool 130 can be connected to the on-board diagnostic (OBD) interface of vehicle 110 via a diagnostic cable; or vehicle diagnostic tool 130 can be connected to vehicle 110 via wireless communication such as Bluetooth.

[0052] The vehicle diagnostic tool 130, also known as a flashing tool or testing device, is a portable intelligent instrument used to detect vehicle faults (110). It can also be used for vehicle information reading, software upgrades, and other operations. For example, the vehicle diagnostic tool 130 flashes the ECU firmware through the On-Board Diagnostics (OBD) interface.

[0053] To address the cybersecurity risks associated with the trends of intelligentization and connectivity, the automotive industry is placing higher demands on vehicle software upgrades and cybersecurity. RSA, an asymmetric encryption algorithm, is widely used in the security mechanisms of vehicle software upgrades, primarily involving key aspects such as identity authentication, data integrity protection, and key exchange. It can effectively prevent data packets from unknown sources from intruding into the vehicle's controller.

[0054] The RSA algorithm has some limitations, mainly in terms of high computational overhead and high storage consumption. In particular, for small controllers such as electric oil pumps, electronic water pumps, seat controllers, and air conditioning controllers, the microcontrollers themselves have low computing power and limited RAM space, making it difficult to run RSA smoothly.

[0055] Based on this, subsequent embodiments of this application provide an RSA signature verification method that can verify RSA signatures even with limited RAM space. For example, upon receiving a data packet from a vehicle diagnostic tool 130, the vehicle ECU can split the RSA signature information, public key exponent, and public key modulus. The data packet contains the RSA signature information. Then, the vehicle ECU transforms the split RSA signature information and public key exponent into the Montgomery domain to obtain the split RSA signature information and public key exponent in Montgomery form. Next, the vehicle ECU performs an accumulation calculation on the split RSA signature information and public key exponent in Montgomery form using an accumulator to obtain an intermediate calculation term. Then, the vehicle ECU performs Montgomery reduction, and based on the intermediate calculation term and the split public key modulus in Montgomery form, obtains the hash value of the parsed data packet. If the hash value of the data packet matches the hash value of the parsed data packet, the vehicle ECU determines that the RSA signature information verification is successful. Afterward, the vehicle ECU can execute the flashing process.

[0056] Please refer to Figure 2 The diagram illustrates a flowchart of a signature verification method provided in an exemplary embodiment of this application. This method is executed by a vehicle ECU, which may optionally be a vehicle ECU. Figure 1 The vehicle ECU is shown. (As shown) Figure 2 As shown, the method may include steps 210 to 250.

[0057] Step 210: Upon receiving the data packet sent by the vehicle diagnostic tool, split the signature information, public key index, and public key modulus; the data packet contains the signature information.

[0058] In this embodiment of the application, the aforementioned signature information refers to RSA signature information.

[0059] In some embodiments, when a vehicle diagnostic tool (TESTER) establishes a connection with a vehicle, the TESTER sends a data packet containing RSA signature information to the vehicle. For example, the TESTER can establish a connection with the vehicle via a diagnostic interface (such as an OBD interface), first converting the RSA signature information into a transport-compatible format, encapsulating it in a Unified Diagnostic Services (UDS) message, and then transmitting the RSA signature information and data packet to the vehicle's ECU via the UDS service. This can be done, for example, using the RoutineControl (0x31) service or the TransferData (0x36) and RequestDownload (0x34) services to send the RSA signature information and data packet to the vehicle.

[0060] In some embodiments, the public key index and public key modulus are released by the key provider (e.g., a server) and directly pre-written into the vehicle ECU's storage. For example, the vehicle ECU stores the public key index and public key modulus in non-volatile memory, such as ROM or FLASH space. During the splitting of the public key index and public key modulus, the vehicle ECU loads the public key index and public key modulus from the ROM or FLASH storage into RAM and performs the splitting.

[0061] For example, taking RSA signature information C, public key exponent e, and public key modulus n as an example, the vehicle ECU splits the RSA signature information C and public key exponent e to obtain C[i], e[j], and n[m], where i, j, and m are all positive integers.

[0062] In some embodiments, the vehicle ECU splits the RSA signature information, public key exponent, and public key modulus into multiple 32-bit arrays. Taking the RSA signature information as RSA-3072 as an example, with a total of 3072 bits, the vehicle ECU splits the RSA signature information, public key exponent, and public key modulus into 96 blocks and stores them in the form of arrays uint32_t C

[96] , uint32_t e

[96] , and uint32_t n

[96] .

[0063] Step 220: Transform the split signature information and the split public key exponent into the Montgomery field to obtain the split signature information and the split public key exponent in Montgomery form.

[0064] During the signature verification phase, a large number of modular exponentiation operations are involved. These operations are computationally intensive and time-consuming when dealing with large integers. In the practical example of this application, the vehicle ECU can optimize the modular exponentiation operations through the Montgomery algorithm, thereby improving the verification efficiency of RSA signatures.

[0065] In this embodiment, the aforementioned transformation of the split signature information and public key exponent to the Montgomery field refers to converting the split signature information and public key exponent into Montgomery form. The vehicle ECU selects an integer R greater than the public key modulus n, typically R = 2. k k is the smallest integer satisfying R > n, such as 3072. Taking the split RSA signature information C[i] and public key exponent e[j] as an example, the vehicle ECU obtains the split RSA signature information in Montgomery form as C'[i] = C[i] * R mod N, and the split public key exponent in Montgomery form as e'[j] = e[j] * R mod N.

[0066] Step 230: Perform cumulative calculations on the Montgomery form split signature information and the Montgomery form split public key exponent using an accumulator to obtain intermediate calculation terms.

[0067] In this embodiment, the vehicle ECU initializes the accumulator, and then obtains the product of the split RSA signature information in Montgomery form and the large number corresponding to the public key exponent through the accumulator to obtain the intermediate calculation term.

[0068] In one possible implementation, step 230 above can be implemented as follows:

[0069] By iterating through the public key index in Montgomery form in the outer loop, at least two public key index blocks in Montgomery form are obtained; by iterating through the RSA signature information in Montgomery form in the inner loop, at least two RSA signature information blocks in Montgomery form are obtained; and at least two RSA signature information blocks in Montgomery form and at least two public key index blocks in Montgomery form are added to the specified positions of the accumulator in turn to obtain intermediate calculation terms.

[0070] In other words, the vehicle ECU first iterates through the public key index e'[j] of each Montgomery form split through the outer loop, and then iterates through the RSA signature information C'[i] of each Montgomery form split through the inner loop, calculates the product of each C'[i] and the current e'[j], and adds the result to the corresponding position of the accumulator register (acc), while processing the carry, to obtain the intermediate calculation term T = C*e.

[0071] Step 240: Obtain the hash value for parsing the data packet by Montgomery reduction, based on the intermediate computational terms and the modulus of the split public key.

[0072] In some embodiments, the vehicle ECU has a pre-set calculation formula for Montgomery reduction. The vehicle ECU substitutes the intermediate calculation terms and the split public key modulus into the calculation formula to obtain the hash value for parsing the data packet.

[0073] Step 250: If the hash value of the data packet matches the hash value obtained from parsing the data packet, the signature information verification is deemed successful.

[0074] In this embodiment, the hash value of the data packet is calculated by the vehicle ECU. For example, the vehicle ECU uses a preset Secure Hash Algorithm (SHA) function (such as SHA-256) to extract the digest information of the data packet and obtain its hash value.

[0075] In some embodiments, if the hash value of the data packet is inconsistent with the hash value parsed from the data packet, the process returns to step 210 to recalculate, or the verification is deemed to have failed.

[0076] In some embodiments, if the RSA signature information is successfully verified, the vehicle ECU performs a flashing process to erase and write data packets to the controller.

[0077] In summary, the solution described in this application allows the vehicle ECU to split the signature information, public key index, and public key modulus contained in the data packet when it receives the data packet from the vehicle diagnostic tool. This splits the data packet into multiple signature information blocks, public key index blocks, and public key modulus blocks. These blocks are then converted to Montgomery form, and an accumulator is used to obtain the intermediate calculation term between the signature information and the public key index. Montgomery reduction is then applied, and the hash value for parsing the data packet is obtained based on the intermediate calculation term and the public key modulus block. If the hash value for parsing the data packet matches the hash value of the data packet, the vehicle ECU can determine that the signature verification is successful. This solution, by splitting the signature information, public key index, and public key modulus, can divide the large integer operations in the signature verification process into multiple blocks, reducing the computational load of each data processing operation and thus reducing RAM usage. This allows for signature verification even when the vehicle ECU's computing power and RAM space are limited.

[0078] Based on the above Figure 2 In one possible implementation of the embodiment shown, step 240 can be implemented as steps 240a and 240b.

[0079] Step 240a: Obtain the reduction parameter according to the first formula; the first formula is:

[0080] q = (acc[0] × μ) mod R;

[0081] Where q is the reduction parameter, acc[0] is the least significant block of the accumulator, μ is the modulo inverse constant, and R is the preselection constant.

[0082] In this embodiment of the application, the above-mentioned modulo inverse constant μ = -n -1 The first formula, mod R, is pre-stored by the vehicle ECU and is used to calculate the reduction parameter.

[0083] In some embodiments, R is a large integer that is modulo coprime to the public key, R = 2. k k is a positive integer; for example, k = 3072.

[0084] Step 240b: Calculate the hash value of the parsed data packet according to the second formula; the second formula is:

[0085]

[0086] Where T' is the hash value of the parsed data packet, T is the intermediate calculation term, q is the reduction parameter, and n is the modulus of the split public key.

[0087] In this embodiment of the application, the second formula described above is pre-stored by the vehicle ECU and is used to calculate the hash value for parsing data packets.

[0088] In this embodiment, during the calculation of q*n, the vehicle ECU multiplies q by n for each block and sums the results to improve computational efficiency. During the process, the vehicle's ECU will Subtracting n from each of the individual blocks sequentially yields the hash value T' for parsing the data packet.

[0089] In the solution of this application embodiment, the vehicle ECU can substitute data into two pre-set formulas (first formula and second formula) to calculate the hash value of the data packet parsing, so as to improve the processing efficiency of calculating the hash value of the data packet parsing.

[0090] Based on the solutions shown in the above embodiments, in one possible implementation, before step 240a, the signature verification method further includes:

[0091] Retrieve the modulo inverse constant from non-volatile memory.

[0092] In this embodiment of the application, the aforementioned modular inverse constant is pre-calculated by the vehicle ECU and stored in a structured format in a non-volatile memory so that the modular inverse constant can be loaded from the non-volatile memory during real-time calculation.

[0093] In some embodiments, the aforementioned non-volatile memory may be ROM space or FLASH space, or other non-volatile memory, which is not limited in this application.

[0094] The modulus inverse constant in the embodiments of this application is used to accelerate the elimination of low-order bits in Montgomery reduction, thereby accelerating real-time computation in the RSA verification process.

[0095] Based on the solutions shown in the above embodiments, in one possible implementation, before step 220, the signature verification method further includes:

[0096] Retrieve the Montgomery constant from non-volatile memory;

[0097] Step 220 above can be implemented as follows:

[0098] Based on the Montgomery constant, the split signature information and the split public key exponent are transformed into the Montgomery field to obtain the split signature information and the split public key exponent in Montgomery form.

[0099] In this embodiment of the application, the Montgomery constant is pre-calculated by the vehicle ECU and stored in a structured format in a non-volatile memory so that the Montgomery constant can be loaded from the non-volatile memory during real-time calculation.

[0100] In some embodiments, the aforementioned non-volatile memory may be ROM space or FLASH space, or other non-volatile memory, which is not limited in this application.

[0101] In some embodiments, the vehicle ECU uses formula R 2 The Montgomery constant is calculated beforehand using mod n, and then the formula C'[i] = MontMul(C[i], R) is applied. 2 Calculate C'[i] = C[i] * R mod N using the formula mod n, and calculate e'[i] = MontMul(e[i], R) based on the formula mod n, n. 2 When calculating e'[i] = e[i] * R mod N, the data can be quickly converted to the Montgomery domain.

[0102] The Montgomery constant in this embodiment is used to quickly convert the split signature information and public key modulus to the Montgomery field, which can avoid real-time division operations and accelerate real-time operations in the verification process.

[0103] Based on the schemes shown in the above embodiments, in one possible implementation, the data packet contains at least two data packet blocks; the above signature verification method further includes:

[0104] Write at least two data packets in blocks into non-volatile memory;

[0105] In the event of a failure to write the first data packet block, a retransmission request is sent to the vehicle diagnostic tool. The retransmission request carries the identification information of the first data packet block and is used to instruct the vehicle diagnostic tool to send the first data packet block to the vehicle ECU.

[0106] Receive the first data packet segment returned by the vehicle diagnostic tool;

[0107] The first data packet is written in blocks to non-volatile memory.

[0108] In some embodiments, the data packets that need to be flashed by the vehicle ECU are divided into at least two data packet blocks by a data source (such as a server or a vehicle diagnostic tool). For example, the above-mentioned at least two data packet blocks can be blocks of fixed size, or they can be dynamically set according to the memory usage, data characteristics, etc. of the vehicle ECU. This application does not limit this.

[0109] In some embodiments, writing at least two data packets into non-volatile memory can be done by writing each data packet into non-volatile memory sequentially to reduce the complexity of a single processing step; or, it can be done by writing a specified number of data packet packets into non-volatile memory in parallel each time to improve the writing efficiency of data packets without affecting the complexity of a single processing step.

[0110] When the first data packet block fails to be written, the vehicle ECU sends a retransmission request to the vehicle diagnostic tool. Accordingly, the vehicle diagnostic tool receives the retransmission request and returns the first data packet to the vehicle ECU according to the identification information of the first data packet block, so that the vehicle ECU can rewrite the first data packet block.

[0111] In some embodiments, the identification information described above is information used to uniquely identify data packet blocks. For example, the identification information may be the number of the data packet block.

[0112] In some embodiments, the vehicle ECU can send a retransmission request to the vehicle diagnostic tool via the Negative Response Code (NRC) of the UDS service. For example, when the vehicle diagnostic tool sends a data packet to the vehicle using 0x36, the vehicle ECU can request the diagnostic tool to retransmit the specified data block by returning NRC 0x13 (request error).

[0113] In this embodiment, the data packet is divided into multiple data packet blocks, which can reduce the complexity of a single processing when the vehicle ECU writes the data packet. If the first data packet block fails to be written, the vehicle ECU can request the vehicle diagnostic tool to re-acquire the first data packet block through a retransmission request. This can avoid retransmitting the entire data packet in the event of a data packet block writing failure, thereby improving the writing efficiency of the data packet.

[0114] Based on the solutions shown in the above embodiments, in one possible implementation, the vehicle ECU includes at least one of the following:

[0115] Electric oil pump ECU, electronic water pump ECU, seat ECU, air conditioning ECU.

[0116] The aforementioned electric fuel pump ECU is used to control the start, stop, and speed of the electric fuel pump, and to regulate fuel pressure to meet the needs of different engine operating conditions (such as starting, idling, and high load). It typically uses an 8-bit or 16-bit microcontroller (such as the 8051 series), with relatively low computing power (approximately a few MHz) and small RAM space (usually in the KB range).

[0117] The aforementioned electronic water pump ECU is used to adjust the water pump motor speed and control the coolant flow rate via PWM signals, achieving rapid warm-up, energy saving, and overheat protection. It typically uses a 16-bit or 32-bit microcontroller (such as STM32), with moderate computing power (approximately tens of MHz) and a large RAM space (up to tens of KB).

[0118] The aforementioned seat ECU is used to control the seat position (forward / backward, height, tilt), heating / ventilation / massage functions, receive seat switch signals, and drive the motor. It typically uses an 8-bit or 16-bit microcontroller, with relatively low computing power (a few MHz to tens of MHz) and small RAM space (KB level).

[0119] The aforementioned air conditioning ECU is used to regulate the air conditioning compressor, blower, dampers, etc., and control the temperature, fan speed, and mode to achieve automatic or manual air conditioning functions. It generally uses a 16-bit or 32-bit microcontroller with moderate computing power (tens of MHz) and a large RAM space (tens of KB to MB).

[0120] In the embodiments of this application, the above solution can be applied to electric oil pump ECU, electric water pump ECU, seat ECU, air conditioning ECU, and can also be applied to other small vehicle ECUs with low single-chip microcomputer computing power and small RAM space. This application does not limit it in this regard.

[0121] Based on the solutions shown in the above embodiments, in one possible implementation, this application proposes a RAM resource-low dependency RSA signature verification method, relating to the field of hybrid transmission technology, and particularly to an electric oil pump RSA signature verification method. New energy vehicle power and transmission systems often require electric oil pumps. An electric oil pump is a combination of an oil pump, a motor, a controller, and its embedded software. The controller controls the motor as a power source to drive the oil pump to provide hydraulic oil for cooling and lubrication.

[0122] like Figure 3 As shown, the above-mentioned electric oil pump RSA signature verification method includes:

[0123] Step 1: Key Generation

[0124] First, a pair of RSA keys is generated by a server or other computer device. The private key contains a private key modulus N and a private key exponent d, and the public key contains a public key modulus n and a public key exponent e. In this embodiment, the private key modulus N is the same as the public key modulus n.

[0125] Step 2: Signature Generation

[0126] The hash value H is calculated from the original information M using the SHA function, and the hash value is then encrypted using the private key to generate signature information C. Here, the original information M refers to the information that needs to be signed and encrypted. In this embodiment, the original information M refers to the data packet that needs to be written.

[0127] For example, taking SHA-256 as an example, the process of generating signature information C is as follows:

[0128] ① Calculate the hash value of the original information M: H(M) = SHA-256(M), resulting in a 256-bit (32-byte) output;

[0129] ② Hash padding: The hash value is extended to 3072 bits (384 bytes) according to the standard (such as PKCS#1v1.5 or PSS). The padding content includes: hash algorithm identifier and random salt value.

[0130] ③ (Blocked) Modular exponentiation: C = H(M) d Mod N, generate signature information (this step can be performed in blocks according to the method in step 6, depending on the resource situation).

[0131] Where H(M) is the hash value of the original message, which is 32 bytes for SHA256; M is the original message, of arbitrary length; C is the signature information, which is 384 bytes for RSA3072; N is the private key modulus, which is 384 bytes for RSA3072; and d is the private key exponent.

[0132] Step 3: Send Signature

[0133] TESTER converts the signature information C into a transport-compatible format, encapsulates it in the form of a UDS message, and transmits the signature information C to the ECU through the UDS service. For example, TESTER uses the RoutineControl (0x31) service or the TransferData (0x36) and RequestDownload (0x34) services to transmit the information.

[0134] Step 4: Pre-calculate constants

[0135] Before performing real-time calculations (such as signature verification), the ECU first calculates and stores key constants offline to accelerate modular multiplication operations and avoid the resource-constrained ECU calculating large parameters in real time.

[0136] In this embodiment of the application, the ECU uses the Montgomery model:

[0137] ① Calculate Montgomery's constant R 2 mod N(R=2 3072 This allows for rapid data conversion to the Montgomery domain, avoiding real-time division operations.

[0138] ② Calculate the modulus inverse constant μ = -N -1 mod2 32 Accelerate the elimination of low-level components in Montgomery's reduction process;

[0139] ③ Store the pre-calculated constants in a structured format for real-time computation. The storage format follows the block computation mode in step 6, and the storage location follows the method in step 5.

[0140] Step 5: Data Classification and Storage

[0141] The ECU receives the signature information C and officially enters the signature verification process.

[0142] In this embodiment, the ECU uses the public key exponent e, public key modulus n, RSA function, SHA function, signature information C, and Montgomery constant R. 2 Constant parameters such as modulo N and the modulo inverse constant μ are stored in ROM or FLASH space, while the calculation results of subsequent processes are stored in RAM space. Before real-time calculation, the ECU can load the required constant parameters from ROM or FLASH storage into RAM.

[0143] Step 6: Parameter Initialization

[0144] Input data is divided into blocks: constant parameters such as the public key modulus n, signature information C, and public key exponent e are all divided into data blocks. For example, for the signature information of RSA-3072, the total number of bits is 3072 bits, the number of blocks is 96 (each block is 32-bit), and it is stored in the form of arrays such as uint32_t n

[96] , uint32_t C

[96] , uint32_te

[96] , etc.

[0145] Step 7: Block Calculation

[0146] The Montgomery modular multiplication and block computation are combined to calculate H′(M) = C. e mod n, where H′(M) is the hash value of the parsed original message, which is 32 bytes for SHA256; M is the original message, of arbitrary length; C is the signature information, which is 384 bytes for RSA3072; n is the public key modulus, which is 384 bytes for RSA3072; and e is the public key exponent.

[0147] ① Montgomery Model

[0148] Call the pre-calculated Montgomery constant R 2 mod n(R=2 3072 (Calculated offline and stored in flash), calculate A′=A×R mod n (where R=2) 3072 );

[0149] Call the pre-calculated modular inverse constant μ = -n -1 mod232 (already calculated offline, stored in flash), calculate T×R- 1 modn;

[0150] Output result: A = A′ × R -1 mod n.

[0151] ② Block calculation

[0152] Calculate A × B mod n (where A and B are both 96 × 32-bit arrays):

[0153] Initialize the accumulator acc

[96] = {0} (store intermediate results), outer loop (traverse each block B[i] of B): calculate each 32-bit block B[i] of B; inner loop (traverse each block A[j] of A): calculate A[j] × B[i] and accumulate it into acc[j] and handle carry (may affect acc[j+1]).

[0154] Calculate the reduction parameter q = acc[0] × μ (only the lower 32 bits are used).

[0155] Eliminate low-order bits: Execute the assignment acc += q × n (make acc[0] become 0);

[0156] Right shift by acc 32 bits (equivalent to dividing by R=2) 32 );

[0157] Final adjustment: If acc is still ≥ n, then subtract n to get the final result H′(M) = C e mod n.

[0158] Step 8: Compare hash values

[0159] Compare the parsed hash value H′(M) with H(M). If they are the same, the signature verification is considered successful. If they are different, you can return to step 6 to recalculate, or you can directly determine that the signature verification has failed.

[0160] Step 9: Flashing Process

[0161] After successful signature verification, the flashing process can begin: erasing and writing data to the controller.

[0162] In summary, the above method reduces RAM usage by dividing large integer operations in RSA into smaller blocks through block computation, processing only a portion of the data at a time; it also reduces RAM usage by reusing the same RAM space to store intermediate variables from different stages through dynamic memory reuse, avoiding the need to allocate independent memory for each step; and it reduces real-time computation by pre-computing and storing fixed parameters. The above method offers the following technical advantages:

[0163] 1) Low memory requirements: RSA verification can be run on microcontrollers with small RAM (traditional methods require tens of KB+), making it suitable for small embedded devices such as electric oil pump controllers.

[0164] 2) Uncompromising security: Fully supports RSA digital signature verification (such as PKCS#1v1.5 / PSS), and complies with the security requirements for software updates in regulations such as UNECER156.

[0165] 3) Low-cost adaptation: It can be deployed without upgrading hardware, reducing the cost for automakers to modify their existing supply chains.

[0166] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0167] Please refer to Figure 4 This diagram illustrates a block diagram of a signature verification apparatus provided in an exemplary embodiment of this application. The apparatus has the functionality to implement the above example; this functionality can be implemented in hardware or by hardware executing corresponding software. Figure 4 As shown, the device may include: a data splitting module 401, a data transformation module 402, a data accumulation module 403, a data calculation module 404, and a signature verification module 405.

[0168] The data splitting module 401 is used to split the signature information, public key exponent, and public key modulus upon receiving a data packet sent by the vehicle diagnostic tool; the data packet contains signature information.

[0169] The data transformation module 402 is used to transform the split signature information and the split public key index to the Montgomery field to obtain the split signature information and the split public key index in Montgomery form.

[0170] The data accumulation module 403 is used to perform accumulation calculations on the Montgomery form split signature information and the Montgomery form split public key index through the accumulator to obtain intermediate calculation items;

[0171] The data calculation module 404 is used to obtain the hash value of the parsed data packet by Montgomery reduction, based on the intermediate calculation items and the modulus of the split public key;

[0172] The signature verification module 405 is used to determine that the signature information has been successfully verified if the hash value of the data packet matches the hash value parsed from the data packet.

[0173] In some embodiments, the data calculation module is used to obtain the reduction parameter according to a first formula; the first formula is:

[0174] q = (acc[0] × μ) mod R;

[0175] Where q is the reduction parameter, acc[0] is the least significant block of the accumulator, μ is the inverse modulus constant, and R is the preselection constant;

[0176] Calculate the hash value of the parsed data packet according to the second formula; the second formula is:

[0177]

[0178] Where T' is the hash value of the parsed data packet, T is the intermediate calculation term, q is the reduction parameter, and n is the modulus of the split public key.

[0179] In some embodiments, the signature verification apparatus further includes: a first invocation module, configured to invoke the modulo inverse constant from a non-volatile memory before obtaining the reduction parameter according to the first formula.

[0180] In some embodiments, the signature verification apparatus further includes: a second calling module, configured to call the Montgomery constant from non-volatile memory before transforming the split signature information and the split public key exponent to the Montgomery field to obtain the split signature information and the split public key exponent in Montgomery form;

[0181] The data transformation module is used to transform the split signature information and the split public key exponent to the Montgomery field based on the Montgomery constant, so as to obtain the split signature information and the split public key exponent in Montgomery form.

[0182] In some embodiments, the data packet includes at least two data packet blocks; the signature verification device further includes: a data writing module, configured to write at least two data packet blocks into a non-volatile memory; in the event that the writing of the first data packet block fails, send a retransmission request to a vehicle diagnostic tool; the retransmission request carries identification information of the first data packet block, and the retransmission request is used to instruct the vehicle diagnostic tool to send the first data packet block to the vehicle ECU; receive the first data packet block returned by the vehicle diagnostic tool; and write the first data packet block into the non-volatile memory.

[0183] In some embodiments, the vehicle ECU includes at least one of the following:

[0184] Electric oil pump ECU, electronic water pump ECU, seat ECU, air conditioning ECU.

[0185] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0186] Please refer to Figure 5 This diagram illustrates a structural block diagram of a computer device according to an embodiment of this application. The computer device 500 can be any electronic device capable of data computation, processing, and storage. The computer device 500 can be used to implement the signature verification method provided in the above embodiments.

[0187] Typically, computer device 500 includes a processor 501 and a memory 502.

[0188] Processor 501 may include one or more processing cores, such as a quad-core processor, a penta-core processor, etc. Processor 501 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 501 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 501 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 501 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0189] The memory 502 may include one or more computer-readable storage media, which may be non-transitory. The memory 502 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 502 are used to store a computer program configured to be executed by one or more processors to implement the signature verification method described above.

[0190] Those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on the computer device 500, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0191] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor, implements the aforementioned signature verification method. Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0192] In an exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the signature verification method described above.

[0193] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0194] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A signature verification method, characterized in that, The method is executed by the vehicle's electronic control unit (ECU), and the method includes: Upon receiving a data packet from the vehicle diagnostic tool, the signature information, public key exponent, and public key modulus are split; the data packet contains the signature information. The split signature information and the split public key index are transformed into the Montgomery field to obtain the split signature information and the split public key index in Montgomery form; The intermediate calculation term is obtained by performing an accumulation calculation on the signature information after the Montgomery form is split and the public key index after the Montgomery form is split by the accumulator. The hash value for parsing the data packet is obtained by Montgomery reduction, based on the intermediate computational term and the modulus of the split public key; If the hash value of the data packet matches the hash value obtained by parsing the data packet, the signature information is deemed to have been successfully verified.

2. The method according to claim 1, characterized in that, The step of obtaining the hash value for parsing the data packet through Montgomery reduction, based on the intermediate computational term and the modulus of the public key after Montgomery decomposition, includes: The reduction parameter is obtained according to the first formula; the first formula is: q = (acc[0] × μ) mod R; Where q is the reduction parameter, acc[0] is the least significant block of the accumulator, μ is the modulo inverse constant, and R is the preselection constant; The hash value of the parsed data packet is calculated according to the second formula; the second formula is: Where T' is the hash value parsed from the data packet, T is the intermediate calculation term, q is the reduction parameter, and n is the modulus of the split public key.

3. The method according to claim 2, characterized in that, Before obtaining the reduction parameter according to the first formula, the method further includes: The modular inverse constant is retrieved from non-volatile memory.

4. The method according to any one of claims 1 to 3, characterized in that, Before transforming the split signature information and the split public key index into the Montgomery field to obtain the split signature information and the split public key index in Montgomery form, the method further includes: Retrieve the Montgomery constant from non-volatile memory; The split signature information and the split public key index are transformed into the Montgomery field to obtain the split signature information and the split public key index in Montgomery form, including: Based on the Montgomery constant, the split signature information and the split public key exponent are transformed into the Montgomery field to obtain the split signature information and the split public key exponent in Montgomery form.

5. The method according to any one of claims 1 to 3, characterized in that, The data packet contains at least two data packet chunks; the method further includes: Write the at least two data packets into non-volatile memory in blocks; In the event of a failure to write the first data packet segment, a retransmission request is sent to the vehicle diagnostic tool; the retransmission request carries the identification information of the first data packet segment, and the retransmission request is used to instruct the vehicle diagnostic tool to send the first data packet segment to the vehicle ECU. Receive the first data packet segment returned by the vehicle diagnostic tool; The first data packet is written into the non-volatile memory in blocks.

6. The method according to any one of claims 1 to 3, characterized in that, The vehicle ECU includes at least one of the following: Electric oil pump ECU, electronic water pump ECU, seat ECU, air conditioning ECU.

7. A signature verification device, characterized in that, The device includes: The data splitting module is used to split the signature information, public key exponent, and public key modulus upon receiving a data packet from a vehicle diagnostic tool; the data packet contains the signature information. The data transformation module is used to transform the split signature information and the split public key index to the Montgomery field to obtain the split signature information and the split public key index in Montgomery form. The data accumulation module is used to perform accumulation calculations on the signature information after splitting in Montgomery form and the public key index after splitting in Montgomery form through an accumulator to obtain intermediate calculation items; The data calculation module is used to obtain the hash value of the parsed data packet by Montgomery reduction, based on the intermediate calculation item and the modulus of the split public key; The signature verification module is used to determine that the signature information has been successfully verified if the hash value of the data packet matches the hash value parsed from the data packet.

8. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the signature verification method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the signature verification method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, which a processor reads from and executes to implement the signature verification method as described in any one of claims 1 to 6.

Images