Software management device and method

Abstract

The invention relates to a software management device and method. The management equipment comprises a first device, and the first device comprises an information extraction unit which is configured to receive at least one transmission message and extract multi-segment information and a first message authentication code from the transmission message; and the synthesis unit is configured to splice the multiple pieces of information to generate synthesis information. The management device further comprises a second device comprising an encryption unit configured to encrypt the synthetic information by using a key to generate a second message authentication code; wherein the first device further comprises a verification unit configured to verify whether the transmission message is secure based on the first message authentication code and the second message authentication code.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to security protection for over-the-air software downloading. Background Art

[0002] At present, with the development of intelligent vehicles, a large number of security and application software and firmware necessary for the operation of vehicle systems are installed in vehicles, and the maintenance of these software and firmware, such as upgrading or installing new software, has become very important. At present, vehicle suppliers or original equipment manufacturers (OEMs) mainly manage vehicle software remotely through over-the-air download technology (OTA), and upgrade the software on the vehicle or install new software by downloading upgrade packages or installing software packages from the maintained server. However, during the OTA transmission process, a security issue faced is that the software data may be maliciously tampered with or damaged in other ways during the download and transmission process, so how to ensure the secure transmission of data has become a problem that needs to be solved. Summary of the invention

[0003] The present invention proposes an improved security verification mechanism based on a trusted execution environment (TEE) mechanism, which is used to verify whether data transmission is secure.

[0004] According to one aspect of the present invention, there is provided a software management device, comprising a first device, including: an information extraction unit, configured to receive at least one transmission message, and extract multiple pieces of information and a first message authentication code from the transmission message; a synthesis unit, configured to splice the multiple pieces of information to generate a synthetic information. The management device also includes a second device, including an encryption unit, configured to encrypt the synthetic information using a key to generate a second message authentication code. The first device further includes a verification unit, configured to verify whether the transmission message is secure based on the first message authentication code and the second message authentication code. In a preferred example of the present invention, the first device and the second device can be implemented by a vehicle-mounted ECU (electronic control unit) respectively.

[0005] According to another aspect of the present invention, a software management device is provided, which supports a rich execution environment (REE) and a trusted execution environment (TEE), and includes: at least one controller; at least one first application operating in the rich execution environment (REE), executed by the at least one controller to receive at least one transmission message, extract multiple pieces of information and a first message authentication code from the transmission message, and splice the multiple pieces of information to generate a composite message; a second application operating in the trusted execution environment (TEE), executed by the at least one controller to encrypt the composite information using a key to generate a second message authentication code; wherein the first application verifies whether the transmission message is secure based on the first message authentication code and the second message authentication code.

[0006] According to another aspect of the present invention, there is provided a software management method implemented by at least one controller, wherein the controller supports a rich execution environment (REE) and a trusted execution environment (TEE), the method comprising: receiving at least one transmission message in a rich execution environment (REE), extracting multiple pieces of information and a first message authentication code from the transmission message, and splicing the multiple pieces of information to generate a composite message; encrypting the composite information using a key in the trusted execution environment (TEE) to generate a second message authentication code; and verifying whether the transmission message is secure based on the first message authentication code and the second message authentication code in the rich execution environment (REE). BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A schematic diagram showing a software management device according to an embodiment is shown;

[0008] Figure 2 The schematic diagram of encoding and generating a transmission message on the server side is shown schematically;

[0009] Figure 3 Schematically shows a schematic diagram of decoding and verifying a transmission message on the vehicle side;

[0010] Figure 4 A schematic diagram showing a software management device according to another embodiment;

[0011] Figure 5 A flowchart of a software management method according to an embodiment is shown. DETAILED DESCRIPTION

[0012] Before any embodiments of the invention are explained in detail, it should be understood that the invention is not limited in its application to the details of construction set forth in the following description or shown in the drawings. The invention is capable of other embodiments and of being practiced or carried out in various ways.

[0013] Figure 1The schematic diagram of a software management device 100 according to an embodiment of the present invention is shown. The software management device 100 is located on a vehicle and is used to manage and maintain system software, applications, firmware, etc. installed on the vehicle. The software management device 100 can communicate with a remote server SVR through a communication interface (not shown in the figure) on the vehicle, for example, through OTA transmission, to receive software upgrades or installations from the server SVR. Here, the remote server SVR can be located at a vehicle supplier or OEM manufacturer, where firmware, software, or applications required by the vehicle are maintained. As shown in the figure, the software management device 100 includes a software update device 200 and a security authentication device 300. The software update device 200 is used to download software updates from the remote server SVR, and after being processed by the security authentication device 300, it verifies whether the downloaded software data is safe, and after passing the verification, updates the pre-installed software of the vehicle or installs new software. In the following description, for convenience, the software, firmware, or applications related to the vehicle are collectively referred to as "software", and the update of the pre-installed software or the installation of new software operations are collectively referred to as "update".

[0014] Typically, the server SVR sends the software to be updated to the vehicle in the form of a transmission message TS via OTA transmission. Here, the server SVR may use any suitable protocol known in the prior art to form the transmission message, such as the (Unified Diagnostic Service) UDS protocol commonly used in the field of vehicle communications. Moreover, based on the size of the software update to be transmitted and the capacity limit of the transmission message, the server SVR may format the updated software into multiple transmission messages and send them to the vehicle accordingly. Figure 2 An exemplary schematic diagram showing the server SVR generating and sending a transmission message according to the present invention is shown.

[0015] like Figure 2 As shown, on the server SVR side, generating a transmission message TS mainly includes three stages:

[0016] Loading phase:

[0017] In this loading phase, the server SVR may call a processor such as a bootloader to perform the following processing: obtain the software data DATA to be updated, and optionally pre-process the software, such as performing necessary encryption protection, dividing it into multiple data subsets when the data volume is large, etc. The protected software data to be transmitted in the transmission message TS is collectively referred to as PD. In addition, for the data PD to be transmitted this time, the server SVR also generates a freshness value FD, and any method known in the prior art, such as a timestamp check or a counter check method, can be used to generate the freshness FD. For example, when a counter is used for implementation, the number of bits can be set to 8 bytes. In addition, the server SVR also allocates a request identifier SID for the current message transmission TS.

[0018] After the Bootloader obtains the freshness FD, protected data PD, and request identifier SID, it splices the data FD, PD, and SID into a data string STR in a predetermined format. Here, the Bootloader can use any format to perform splicing, such as splicing the beginning and the end into STR in the order of SID→PD→FD, or interweaving the data FD, SID, and PD in other predetermined formats to form STR. The Bootloader then submits the spliced ​​data string STR for security authentication.

[0019] HSM certification stage:

[0020] According to one example, the server SVR uses a hardware security module (HSM) to complete the secure encryption authentication of the message to be transmitted. Here, the HSM can be operated by an entity independent of the Bootloader or the server SVR. The hardware security module (HSM) receives the data string STR uploaded by the Bootloader and uses an encryption algorithm such as the Advanced Encryption Standard AES128 algorithm to perform encryption operations on the data string STR. Here, the encryption operation is completed using a pre-stored key K to generate a message authentication code (MAC). It should be pointed out here that in the loading phase, the purpose of performing splicing is to ensure that each data string STR has the same standard sequence length for subsequent encryption. Therefore, if the original data string STR sequence is longer than the standard length, truncation processing is performed; if it is shorter than this standard length, padding processing such as padding with 0 is performed.

[0021] Transmission phase:

[0022] In the transmission phase, the server SVR encapsulates the message authentication code MAC from the authentication phase together with the freshness FD, the protected data PD, and the request identifier SID into a transmission message TS. For example, in this example, it can be encapsulated according to the UDS protocol and sent to the target vehicle through the OTA transmission channel, for example, to the software management device 100. Here, the target vehicle can be either a vehicle actively determined by the server SVR or a vehicle that sends a software update request to the server SVR. It should be pointed out here that, due to the limitation of the message transmission capacity, according to the example of the present invention, the freshness FD can be truncated in a predetermined manner during the loading phase, as described above, and / or the generated message authentication code MAC can be truncated as needed and in a predetermined manner during the HSM authentication phase. Thus, the truncated FD and / or MAC is encapsulated into the UDS transmission message TS during the transmission phase.

[0023] In addition, if the software data is large, the data can be divided into N protected data PD1-PD N , and through N transmission messages TS1~TS N Sent to the target vehicle, where each transmission message TS i It not only contains the protected data PD of this transmission i , and also includes the freshness FD generated specifically for this transfer i and the assigned request identifier SID i .

[0024] Back to Figure 1 According to an example of the present invention, the software updating apparatus 200 in the software management device 100 receives and processes the transmission message TS from the server SVR. Figure 1 As shown, the software updating device 200 includes an information extraction unit 201, a synthesis unit 202, a verification unit 203 and a software updating unit 204, wherein the information extraction unit 201 decodes the received transmission message TS, for example, in this example, according to the UDS protocol, extracts the freshness FD, the protected data PD, the request identifier SID and the message authentication code MAC from the transmission message TS. The synthesis unit 202 splices the extracted data FD, PD and SID into a synthetic message, i.e., the data string STR in this example, in the same splicing method agreed with the server SVR. It should be pointed out here that in order to ensure that the data transmission process is not damaged, the synthesis unit 202 can also perform error checking on the data after receiving each data, such as performing CRC check on the freshness FD.

[0025] In this example, the security authentication device 300 is a hardware security module HSM running in a secure and independent environment, which communicates with the software update device 200 through a secure application interface (API) and receives the data string STR from the software update device 200. As shown in the figure, the security authentication device 300 includes an encryption unit 301. After receiving the data string STR from the software update device 200, the key K is used to perform an encryption operation on the synthesized data string STR to generate a message authentication code MAC′. Here, the key K used by the encryption unit 301 is the same as the key K used by the server SVR side when generating the transmission message TS, and can be generated by the same key generator and distributed to the server SVR and the vehicle. Here, the encryption algorithm used by the encryption unit 301 is the same as the algorithm used by the server SVR side when generating MAC, for example, the AES128 algorithm is also used. In addition, according to the present invention, the key K is stored in a memory 302 that can only be accessed or authorized to be accessed by the security authentication device 300, and cannot be accessed by other external systems, devices (including, for example, the software update device 200) or software.

[0026] Subsequently, the security authentication device 300 returns the message authentication code MAC′ to the software update device 200. As shown in the figure, the software update device 200 also includes a verification unit 203, which is used to match the message authentication code MAC′ from the security authentication device 300 with the message authentication code MAC extracted from the transmission message TS to verify whether the current transmission message TS is tampered with or damaged. In another example, after receiving the message authentication code MAC′, the verification unit 203 further determines whether its length exceeds the predetermined constraint condition, and truncates the message authentication code MAC′ if it exceeds, so as to compare the truncated message authentication code MAC′ with the message authentication code MAC extracted from the transmission message TS. Figure 3 The process of decrypting and verifying the transmission message implemented by the software management device 100 is shown. Figure 2 The process of encrypting and generating a transmission message on the server side is shown to be the opposite.

[0027] In a further example of the present invention, when the verification unit 203 determines that the two message authentication codes MAC′ match the MAC, a verification result is generated that the current message TS is secure, and thus the software update device 200 can use a software update unit 204 to execute a software update program based on the protected data PD in the transmission message TS, thereby updating the software on the vehicle. It should be noted here that when this software update is sent to the target vehicle via N transmission messages TS, if all the authentications are passed, the update unit 204 uses each transmission message TS to verify that the software is secure. i SID in i To convert the protected data PD iReassemble into complete software data PD = {PD1, PD2, PD3, ... PD N ,}, and use the combined software data PD to update the software.

[0028] According to the above embodiment of the present invention, the software update device 200 and the verification device 300 in the software management device 100 are respectively implemented by a dedicated vehicle-mounted electronic control unit (ECU), wherein each unit in the software update device 200 can work under a rich execution environment (REE); and the verification unit 301 in the authentication device 300 and the memory storing the key K can be configured to work under a trusted execution environment (TEE), thereby realizing secure isolation verification of the transmission message. In another example of the present invention, the software update device 200 and the verification device 300 can be implemented by the same vehicle-mounted ECU, and the security verification purpose of the present invention can still be achieved by establishing a rich execution environment (REE) and a trusted execution environment (TEE) in the ECU respectively. Figure 4 A schematic diagram of a software management device 400 according to this example is shown.

[0029] As shown in the figure, the management device 400 supports both the rich execution environment (REE) and the trusted execution environment (TEE), wherein the operating system under the REE can be Linux or Android, etc., and the operating system under the TEE can be, for example, Trusty. A software management program running under the REE operating system, such as an update application UA, is installed in the management device 400. The program is responsible for downloading the transmission message TS of the software update from the remote server SVR in an OTA manner through the communication interface, and is responsible for the update service of the software in the vehicle. As shown in the figure, the management device 400 includes an ECU 401 and a memory 402, wherein the ECU 401 is used to execute the application UA ​​to implement the corresponding software update operation; and the memory 402 is used to store system software such as the operating system Linux under the REE environment, applications such as UA, firmware, and other data.

[0030] Generally, TEE is a secure operating environment. The processing of resources and data of applications under TEE is executed in a trusted environment. The software and hardware resources accessible by TEE are separated from the REE environment and have their own execution space. Therefore, according to the example of the present invention, the memory 403 used for the TEE environment is unavailable or invisible to applications in the REE environment, and cannot be accessed by other external programs and devices. In the present invention, the key K and encryption algorithm used for verification, such as AES128, are stored only in the memory 403 accessible in the TEE environment. In addition, as Figure 4As shown, the management device 400 includes a trusted application TA running in a TEE environment, and uses a key K and an encryption algorithm to verify whether a transmission message TS received by an update application UA ​​in an OTA manner is secure.

[0031] With previous reference Figure 1 The operation of the software management device 100 described above is similar. In this embodiment, the ECU 401 can implement the operation of the information management unit 200 by executing the application UA, and implement the operation of the authentication device 300 by executing the application TA, which will not be repeated here.

[0032] In other embodiments of the present invention, the authentication device 300 notifies the software update device 200 or the TA notifies the UA of the authentication code MAC′ by setting a shared memory, such as the memory 402. For example, after the TA generates the authentication code MAC′, it can be placed in the shared memory 402, so that the UA obtains the MAC′ by monitoring the shared memory.

[0033] Figure 5 A flowchart of a security verification and update method according to an embodiment of the present invention is shown below. Figure 3 The decoding process shown in the figure is used to describe the process shown in the figure. In this example, it is assumed that the software to be updated is divided into N transmission messages TS1 to TS N As shown in the figure, in step 501, a transmission message TS downloaded from a remote server SVR is received via OTA. i , where 1≤i≤N, and according to the transmission message protocol such as UDS, the received transmission message TS i Decode to extract the data transfer request identifier SID i , protected data PD i 、The freshness FD corresponding to the current transmission i And the message authentication code MAC i .

[0034] In step 502, the extracted identifier SID is concatenated according to a predetermined concatenation format. i , protected data PD i 、The freshness FD corresponding to the current transmission i Splice into a data string STR i It should be pointed out here that in order to ensure that the data transmission process is not damaged, the data can also be error checked before splicing the data, such as the freshness FD i Perform CRC check, etc.

[0035] Then, in step 503, in the hardware security module HSM, for example, in the TEE environment, the data string STR is encrypting using the key K stored in the hardware security module HSM. i Encrypt to generate a message authentication code MAC i Here, the same algorithm as that used by the server SVR side to generate the message authentication code MAC may be used, for example, the AES128 algorithm may also be used for encryption.

[0036] In step 504, the message authentication code MAC generated in step 503 is received. i ′, and determine the message authentication code MAC i 'Whether it is related to the transmission message TS i The message authentication code MAC extracted from i If there is no match, it indicates that the current transmission message may be tampered with, or a transmission error has occurred. Therefore, in step 505, the software management device may abandon the current transmission message and send a retransmission request to the remote server SVR, which includes the SID of the current transmission. i , thereby instructing the server SVR to only retransmit the i The protected data PD indicated i This method is particularly suitable for software updates that are divided into multiple, for example, N transmission messages TS1 to TS N In another example of the present invention, before performing the matching operation in step 504, the message authentication code MAC may be further determined. i ′ exceeds the predetermined constraint, and if so, the message authentication code MAC i ′ is truncated, thereby converting the truncated message authentication code MAC i ′ and message authentication code MAC i Make a comparison.

[0037] If the MAC is determined in step 504 i ′ and MAC i If the transmission message TS i The protected data extracted from PD i Cache in a memory; at the same time, determine whether all N transmission messages have been received for this software update. If not, the process returns to step 501 to continue receiving the next transmission message TS i+1 If it is determined that all N transmission messages TS1 to TS N If the received signal is received, the process goes to step 507.

[0038] In step 507, the cached data PD1 to PD NAssemble into complete software update data PD, and then update the target software on the vehicle by executing the software update program.

[0039] Although the exemplary software management device and method of the present invention are described above in conjunction with specific examples, those skilled in the art will also recognize that the various illustrative units and method steps described in conjunction with the contents disclosed herein can be implemented as electronic hardware, computer software, or a combination of the two. For example, the various units within the software management device 100 according to the present invention can be implemented as a processor or a main controller and a memory, wherein the memory stores various modules in the form of computer programs, wherein the processor can implement the control and method of the present invention by executing these modules. In addition, another embodiment of the present invention provides a machine-readable medium having machine-readable instructions stored thereon, which, when executed by the processor, causes the processor to execute any of the aforementioned methods disclosed herein. These embodiments are also within the scope of protection of the present invention.

Claims

1. A software management device, comprising: The first device comprises: an information extraction unit, configured to receive at least one transmission message and extract a plurality of pieces of information and a first message authentication code from the transmission message; A synthesis unit configured to combine the multiple pieces of information to generate a synthesized information; A second device, comprising an encryption unit, configured to encrypt the composite information using a key to generate a second message authentication code; The first device further includes a verification unit configured to verify whether the transmission message is secure based on the first message authentication code and the second message authentication code.

2. A software management device as claimed in claim 1, wherein the first device is a first on-vehicle ECU, and the second device is a second on-vehicle ECU supporting a trusted execution environment (TEE), wherein the key is stored in a memory dedicated to the second on-vehicle ECU and accessible only in the TEE environment.

3. The software management device of claim 1 or 2, wherein the plurality of pieces of information in each of the at least one transmission message include a data transmission request identifier, protected data for software update or installation, and freshness associated with the transmission message; wherein the combining unit combines the data transmission request identifier, the protected data and the freshness into a data string in a predetermined manner; The encryption unit generates the second message authentication code by encrypting the data string using the key.

4. The software management device of claim 3, wherein the verification unit is further configured to: truncate the second message authentication code according to a predetermined constraint condition; The verification unit compares the truncated second message authentication code with the first message authentication code.

5. The software management device of claim 3, wherein the verification unit is further configured to: when it is determined that the second message authentication code matches the first message authentication code, generate an authentication result indicating that the current transmission message is secure; The first device further comprises: An updating unit is configured to update the vehicle software using the protected data in the at least one transmission message based on the authentication result.

6. The software management device of claim 2, wherein the freshness indicates the transmission real-timeness of the currently transmitted message.

7. A software management device, supporting a rich execution environment (REE) and a trusted execution environment (TEE), comprising: at least one controller; at least one first application operating in a rich execution environment (REE), executed by the at least one controller to receive at least one transmission message, extract a plurality of pieces of information and a first message authentication code from the transmission message, and concatenate the plurality of pieces of information to generate a composite message; a second application operating in a trusted execution environment (TEE), executed by the at least one controller to encrypt the composite information using a key to generate a second message authentication code; The first application verifies whether the transmission message is secure based on the first message authentication code and the second message authentication code. 8 . The software management device of claim 7 , further comprising a memory configured to store the key and to be accessed by the second application only in the TEE environment.

9. The software management device of claim 7, wherein the plurality of pieces of information in each of the at least one transmission message include a data transmission request identifier, protected data for software update or installation, and freshness associated with the transmission message; wherein the first application concatenates the data transmission request identifier, the protected data, and the freshness into a data string in a predetermined manner; The second application generates the second message authentication code by encrypting the data string using the key.

10. The software management device of claim 9, wherein the first application is further configured to: truncating the second message authentication code according to a predetermined constraint condition; The truncated second message authentication code is compared with the first encrypted message authentication code.

11. The device of any one of claims 7-10, wherein the first application is configured to update the vehicle software based on the protected data in the at least one transmission message when it is determined that the second message authentication code matches the first message authentication code.

12. A software management method implemented by at least one controller, the controller supporting a rich execution environment (REE) and a trusted execution environment (TEE), the method comprising: receiving at least one transmission message in a rich execution environment (REE), extracting a plurality of pieces of information and a first message authentication code from the transmission message, and concatenating the plurality of pieces of information to generate a composite message; Encrypting the synthesized information using a key in a trusted execution environment (TEE) to generate a second message authentication code; In a rich execution environment (REE), whether the transmission message is secure is verified based on the first message authentication code and the second message authentication code. The method of claim 12 , wherein the key is accessible only in the TEE environment.

14. The method of claim 13, wherein the plurality of pieces of information in each of the at least one transmission message comprises a data transmission request identifier, protected data for software update or installation, and a freshness associated with the transmission message; Wherein splicing the multiple pieces of information further comprises: The data transmission request identifier, the protected data and the freshness are concatenated into a data string in a predetermined manner.

15. The method of claim 14, wherein verifying whether the transmission message is secure based on the first message authentication code and the second message authentication code further comprises: truncating the second message authentication code according to a predetermined constraint condition; The truncated second message authentication code is compared with the first encrypted message authentication code.

16. The method of any one of claims 12 to 15, further comprising: When it is determined that the second message authentication code matches the first message authentication code, the vehicle software is updated based on the protected data in the at least one transmission message.

17. A readable storage medium having a machine-readable program stored thereon, wherein when the machine-readable program is executed by at least one processor, the processor is caused to implement the method of any one of claims 12 to 16.

Images