Commands signed by VIN ESN and the local trust network at the vehicle level

Abstract

The present disclosure provides "Commands Signed by VIN ESN and a Vehicle-Level Local Trust Network", where a vehicle gateway is connected to a telematics control unit (TCU) and multiple electronic control units (ECUs). The gateway is programmed to: receive a command from the TCU, the command specifying an electronic serial number (ESN) of a target ECU among the ECUs; and in response to verifying that the ESN of the target ECU is included in the trust network, forward the command to the target ECU.

Description

Technical Field

[0001] Aspects of the present disclosure generally relate to a local trust network for processing remote commands intended for target vehicle components. Background Art

[0002] As some non - limiting possibilities, telematics services can include navigation, turn - by - turn direction, vehicle health reports, local business searches, accident reporting, and hands - free calling. In some cases, the vehicle occupants can request these services. In other cases, a remote server can request these services. For example, a vehicle can receive a request to unlock the vehicle from a remote server, and the vehicle can receive the request and command the doors to unlock. Summary of the Invention

[0003] In one or more illustrative examples, a system includes a gateway of a vehicle that is connected to a telematics control unit (TCU) and a plurality of electronic control units (ECUs), and is programmed to: receive a command from the TCU that specifies an electronic serial number (ESN) of a target ECU among the ECUs; and forward the command to the target ECU in response to verifying that the ESN of the target ECU is included in a trust network stored in the gateway.

[0004] In one or more illustrative examples, a method includes: verifying, by a gateway of a vehicle, whether an ESN of a target ECU of a received command is included in a trust network stored in the gateway; if so, forwarding the command to the target ECU; and if not, verifying that the target ECU is trustworthy based on a trust response to a trust request sent by the gateway to multiple sub - networks of the vehicle.

[0005] In one or more illustrative examples, a non - transitory computer - readable medium includes instructions that, when executed by a processor of a vehicle gateway, cause the gateway to verify whether an ESN of a target ECU of a received command is included in a trust network stored in the gateway; if so, forward the command to the target ECU; and if not, verify that the target ECU is trustworthy based on a trust response to a trust request sent by the gateway to multiple sub - networks of the vehicle. Brief Description of the Drawings

[0006] Figure 1 An example system topology for processing commands transmitted via a gateway to various ECUs of a vehicle is shown;

[0007] Figure 2 An example process for processing commands intended for a target ECU is shown. Detailed Description

[0008] As needed, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely illustrative of the present invention, and the present invention can be embodied in various alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of particular components. Accordingly, the specific structural details and functional details disclosed herein should not be construed as limiting, but merely as representative to teach one skilled in the art to use the present invention in various ways.

[0009] As the number of connected applications in the vehicle environment continues to expand, the remote operation of vehicle electronic control units (ECUs) has been increasing. These remote operations typically operate by sending security commands from a cloud server to the vehicle ECU. Some of the vehicle ECUs have a large computing capacity to store symmetric keys for encrypting and decrypting security commands. Examples of such ECUs may include telematics control units (TCUs) or gateways. However, due to cost pressure or limited ECU resources, other ECUs in the vehicle lack symmetric keys.

[0010] In the case of using the current security method, commands signed with an ESN (electronic serial number) can be sent to the target ECU. However, no confirmation is performed to ensure the correspondence between the VIN (vehicle identification number) and the ESN (electronic serial number) of the target ECU. In addition, the current method does not confirm any association between the vehicle gateway ESN and the target ECU ESN.

[0011] In the improved method, commands signed by VIN and ESN can be sent to the gateway as symmetric key encrypted commands. The gateway (e.g., from the TCU) receives the encrypted commands and uses the symmetric key to decrypt the commands. The received commands can be intended to be provided to the target ECU. However, before the gateway sends the commands to the target ECU, the gateway can verify the local trust network to confirm whether the target ECU is trustworthy. For example, the gateway TCU can query whether the electronic serial number (ESN) of the target ECU and the vehicle identification number (VIN) of the vehicle exist in the local trust network in the payload of the signed command. If the local trust network does not contain the association of VIN and ESN (vehicle and target ECU) or the association of ESN and ESN (gateway and target ECU), the gateway performs a trust test by sending questions such as "Who are you? Where are you?" to the target ECU. In response to this trust test, the target ECU can respond with the VIN and ESN via the encrypted CAN FD / secure Ethernet publish / subscribe mechanism. The gateway can receive this VIN and ESN and can verify the VIN from its secure location and associated trusted known sources. If the verification is successful, the gateway / TCU can add the target ECU to the local trust network and can forward the received command to the target ECU. Thus, in the case of using the local trust network, the gateway can operate as a firewall to forward commands to the target ECU. Additional aspects of the present disclosure are discussed in detail below.

[0012] Figure 1 An example system topology 100 for processing commands 114 transmitted to various ECUs 104 of a vehicle 102 via a gateway 108 is shown. Each ECU 104 is connected to one of a plurality of subnets 110. An in-vehicle infotainment unit (TCU) 106 is included to facilitate communication between various components of the vehicle 102 and various components of other vehicles 102 and / or mobile devices via an external network and an in-vehicle network (not shown). The TCU 106 can be connected to a backbone 112 portion of the system topology 100 and can communicate with the ECU 104 via the gateway 108. Although Figure 1 the example system topology 100 is shown, the example components shown are not intended to be restrictive. In fact, the system topology 100 can have more or fewer components and can use additional or alternative components and / or implementations. As an example, the ECU 104 and the TCU 106 can each be connected to one or more nodes of the same or different types as the nodes of both the subnet 110 and the backbone 112.

[0013] Vehicle 102 can be, for example, various types of automobiles, crossover utility vehicles (CUVs), sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), boats, airplanes, or other mobile machines for transporting people or goods. In many cases, vehicle 102 can be driven by an internal combustion engine. As another possibility, vehicle 102 can be a hybrid electric vehicle (HEV) driven by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electric vehicle (PHEV), or a parallel / series hybrid electric vehicle (PSHEV). Since the type and configuration of vehicle 102 can vary, the operating characteristics of the vehicle can vary accordingly. As some other possibilities, vehicle 102 can have different characteristics regarding passenger capacity, towing capacity, and power, as well as storage capacity.

[0014] ECU 104 can include various hardware components and software components and can be configured to monitor and manage various vehicle functions in response to the vehicle 102 battery and / or driveline. Thus, ECU 104 can include one or more processors (e.g., microprocessors) (not shown) configured to execute firmware programs or software programs stored on one or more storage devices (not shown) of ECU 104. Although ECU 104 is shown as a separate component, vehicle ECU 104 can share physical hardware, firmware, and / or software such that functions from multiple ECU 104s can be integrated into a single ECU 104, and the functions of various such ECU 104s can be distributed across multiple ECU 104s.

[0015] The ECU 104 may include: a powertrain controller 104-A configured to manage operating components related to one or more vehicle power sources, such as an engine, a battery, etc.; a transmission controller 104-B configured to manage power transfer between the vehicle powertrain and the wheels; a body controller 104-C configured to manage various power control functions, such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification; a headlamp control module (HCM) 104-D configured to control the lamp on / off setting; a mobile device or other local vehicle 102 device; an advanced driver assistance system (ADAS) 104-E, such as adaptive cruise control or automatic braking; a climate control management controller 104-F configured to monitor and manage heating and cooling system components (e.g., compressor clutch, blower fan, temperature sensor, etc.); and a global positioning system (GPS) controller 104-G configured to provide vehicle location information. It should be noted that these are merely examples, and vehicles 102 with more, fewer, or different ECUs 104 may be used.

[0016] The TCU 106 may include one or more processors (not shown) (e.g., a microprocessor) configured to execute firmware programs or software programs stored on one or more corresponding storage devices of the TCU 106. The TCU 106 may include a modem or other network hardware to facilitate communication between the vehicle 102 and one or more networks external to the vehicle 102. As some non-limiting examples, these external networks may include the Internet, a cable television distribution network, a satellite link network, a local area network, a wide area network, and a telephone network.

[0017] Vehicle 102 may also include a gateway 108. In one example, the gateway 108 may implement the functions of a Smart Data Link Connector (SDLC). The gateway 108 may be configured to facilitate data exchange between vehicle ECUs 104. The gateway 108 may be further configured to facilitate data exchange between vehicle ECUs 104 and a TCU 106 located on backbone 112. In one example, vehicle ECUs 104 and TCU 106 may communicate with the gateway 108 using a CAN communication protocol, such as but not limited to High-Speed (HS) CAN, Medium-Speed (MS) CAN, or Low-Speed (LS) CAN. Different subnets 110 may utilize different CAN protocol speeds. In one example, one or more of the subnets may implement HS-CAN, while one or more other subnets 110 may implement MS-CAN. In other examples, the gateway 108 may be configured to use one or more of an Ethernet network, a Media Oriented Systems Transport (MOST) network, a FlexRay network, or a Local Interconnect Network (LIN) to facilitate communication.

[0018] One or more of the subnets 110 may define a master subnet, which may be referred to as backbone 112. The backbone 112 may include a portion of the system topology 100 that is configured to act as a communication junction for other subnets 110 of the vehicle 102. Thus, the backbone 112 may be configured to manage and route data traffic in a greater volume of data than that provided via other subnets 110. When using the message handling features of the gateway 108, the gateway 108 may be configured to transmit message frames between a TCU 106 located on the backbone 112 and one or more vehicle ECUs 104 located on other subnets 110.

[0019] The gateway 108 may be configured to identify on which subnet 110 each of the ECUs 104 and TCU 106 is located. This may be done based on the corresponding physical network addresses of the ECUs 104 and TCU 106. In one example, in response to receiving a request to route a message to a given ECU 104 or TCU 106, the gateway 108 may query a storage device to identify the network address corresponding to the ECU 104 or TCU 106. For example, the gateway 108 may include a storage device configured to store network addresses, and a routing pattern that defines which messages are routed to which subnets 110 and / or backbone 112. The routing may be determined by the gateway 108 based on predefined parameters included in the message, such as the type of the message and / or an identifier of the ECU 104 or TCU 106 that specifies the source and / or destination of the message.

[0020] In some examples, a subset of the ECUs 104 may receive a key assigned to the ECU 104 at build time. This can be referred to as being performed during the vehicle operation (VO) phase. Key distribution can establish trust relationships between different sets of ECUs 104 on the same vehicle 102, which can enable authenticated communication between the ECUs 104. To minimize the impact on the VO process during pre-roll and at dynamic and static end-of-line (EOL) stations, the process is initiated with a simple diagnostic request during pre-roll and works in the background when the key is in the ON position.

[0021] Command 114 can be sent from the cloud server 116 to the vehicle 102. Command 114 can be a request to perform an operation (such as unlocking a vehicle door) on an ECU 104 of the vehicle 102. Command 114 can be received by the TCU 106 and provided to the gateway 108 for transmission to the target ECU 104. For those ECUs 104 that maintain the key, confirmation of Command 114 can be performed by the target ECU 104.

[0022] However, some of the ECUs 104 may not have the ability to store the key or may lack the processing power necessary to use such a key to decrypt messages. In such examples, confirmation of messages transmitted to the ECU 104 can be performed through additional processing at the gateway 108. To facilitate this processing, the gateway 108 can host a trust network 118. The trust network 118 can maintain status information that indicates which ECUs 104 have been confirmed by the gateway 108 as trustworthy. By using the trust network 118, the gateway 108 can automatically filter Command 114 intended for the target ECU 104 from the server 116 by ensuring that the target ECU 104 is trusted.

[0023] Figure 2 An example process 200 for processing Command 114 intended for a target ECU 104 is shown. In one example, process 200 can be executed by the system 100 as described above.

[0024] At 202, the vehicle 102 receives an encrypted Command 114 from the server 116. In one example, Command 114 can be a request to unlock the doors of the vehicle 102 issued to the body controller 104-C. In another example, Command 114 can be a request to set a pre-conditioned temperature of the passenger compartment of the vehicle 102 issued to the climate control management controller 104-F. In yet another example, Command 114 can be a request to update the transmission program of the vehicle 102 issued to the transmission controller 104-B. Command 114 can be received by the TCU 106 and can be passed by the TCU 106 to the gateway 108 via the backbone 112.

[0025] At 204, vehicle 102 decrypts command 114. In one example, gateway 108 may use the key assigned to vehicle 102 to decrypt command 114. In some cases, the key may be a symmetric key that is the same as the key used by server 116 to encrypt command 114. In other cases, the key may be a decryption key assigned to vehicle 102 that may be used to decrypt command 114 encrypted by server 116 using an encryption key corresponding to the decryption key.

[0026] At 206, vehicle 102 identifies target ECU 104 of command 114. In one example, a field of command 114 may indicate the ESN of ECU 104 (e.g., body controller, etc.) that vehicle 102 is intended to receive command 114, and gateway 108 may use this field to identify target ECU 104. In another example, command 114 may indicate an expected action, and gateway 108 may use the action mapping reaching ECU 104 to identify target ECU 104.

[0027] At 208, vehicle 102 determines whether target ECU 104 is trustworthy. In one example, vehicle 102 may access trust network 118 to determine whether the ESN of target ECU 104 has previously been indicated as trustworthy. In one example, trust network 118 may store the association of the ESN of ECU 104 with the VIN of vehicle 102 such that if the ESN appears within trust network 118, then the ESN has been identified as trustworthy for the VIN of vehicle 102. In another example, trust network 118 may store the association of the ESN of ECU 104 of vehicle 102 with the ESN of gateway 108 of vehicle 102 such that if the ESN appears within trust network 118, then the ESN has been identified as trustworthy for gateway 108. If the ESN of ECU 104 appears to be trustworthy in trust network 118, control passes to operation 210. Otherwise, control passes to operation 212.

[0028] At 210, vehicle 102 forwards the command to target ECU 104. In one example, gateway 108 may provide command 114 to target ECU 104 via subnet 110 to which target ECU 104 is connected. After operation 210, process 200 ends.

[0029] At 212, vehicle 102 sends a trust request to target ECU 104. In one example, the trust test may include a request issued to subnet 110 for ECU 104 to reply indicating on which subnet 110 ECU 104 is located. In another example, the trust test may include a request issued to subnet 110 for other specific information about ECU 104 (such as version control information).

[0030] At 214, vehicle 102 receives a trust response from target ECU 104. In one example, ECU 104 may respond to the trust request on subnet 110 to which ECU 104 is connected. The trust response may include, for example, the ESN of ECU 104 and the VIN of vehicle 102. In one example, the trust response may be provided in encrypted form. The encryption may include, for example, pre-computed versions of both the ESN and the VIN encrypted using a symmetric key known to gateway 108.

[0031] At 216, vehicle 102 confirms the trust response from target ECU 104. As some examples, gateway 108 may verify that the trust response has been received, that the request has been correctly decrypted, and / or that the VIN matches the VIN of vehicle 102. At 218, vehicle 102 determines whether the confirmation is successful. If so, control passes to operation 220. If not, control passes to operation 222.

[0032] At 220, vehicle 102 adds target ECU 104 to trust network 118. For example, gateway 108 may add the ESN of target ECU 104 to trust network 118 to indicate future commands 114 that may be forwarded from target ECU 104. Trust network 118 may also specify on which of subnets 110 target ECU 104 is located. After operation 220, control passes to operation 210 to forward command 114 to target ECU 104.

[0033] At 222, vehicle 102 discards command 114. For example, since gateway 108 cannot confirm target ECU 104, command 114 is not sent. After operation 222, process 200 ends.

[0034] The computing devices described herein (such as ECU 104, TCU 106, gateway 108, and server 116) generally include computer-executable instructions, where the instructions may be executed by one or more computing devices (such as those listed above). The computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and / or technologies, the variety of programming languages and / or technologies including but not limited to any single one of the following or combinations thereof: Java TM , C, C++, C#, Visual Basic, JavaScript, Python, Perl, PL / SQL, etc. Generally speaking, a processor (e.g., a microprocessor) receives instructions from, for example, a memory, a computer-readable medium, etc. and executes the instructions, thereby performing one or more processes, including one or more of the processes described herein. A variety of computer-readable media may be used to store and transmit such instructions and other data.

[0035] Regarding the processes, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as occurring in a certain ordered manner, such processes can be implemented using the steps executed in an order different from that described herein. It should also be understood that certain steps can be executed simultaneously, other steps can be added, or certain steps described herein can be omitted. In other words, the description of the process herein is provided to illustrate certain embodiments and should in no way be construed as limiting the claims.

[0036] Accordingly, it should be understood that the above description is intended to be illustrative and not restrictive. After reading the above description, many embodiments and applications other than the provided examples will be apparent. The scope should not be determined with reference to the above description, but rather with reference to the appended claims and the full scope of equivalents to which those claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and the disclosed systems and methods will be incorporated into such future embodiments. In summary, it should be understood that modifications and variations to the application are possible.

[0037] Unless expressly indicated to the contrary herein, all terms used in the claims are intended to be given their broadest reasonable construction and their ordinary meaning as understood by those skilled in the art of the technology described herein. Specifically, the use of singular articles such as "a," "an," "the," "said," etc. should be understood to refer to one or more of the indicated elements unless the claim expressly states to the contrary.

[0038] The abstract of the disclosure is provided to enable the reader to quickly ascertain the essence of the technical disclosure. The submitted abstract of the specification should be understood to not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing detailed description, it can be seen that various features are combined in various embodiments to make the disclosure more fluent. This method of the disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than those expressly recited in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in less than all of the features in a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the detailed description, and each claim stands on its own as a separately claimed subject matter.

[0039] While the above describes exemplary embodiments, this does not indicate that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are descriptive rather than limiting, and it should be understood that various changes can be made without departing from the essence and scope of the invention. In addition, the features of various implementation embodiments can be combined to form additional embodiments of the invention.

[0040] According to the present invention, there is provided a system having a gateway of a vehicle, the gateway being connected to a telematics control unit (TCU) and a plurality of electronic control units (ECUs), and being programmed to: receive a command from the TCU, the command specifying an electronic serial number (ESN) of a target ECU among the ECUs; and in response to verifying that the ESN of the target ECU is included in a trust network stored in the gateway, forward the command to the target ECU.

[0041] According to one embodiment, the gateway is further programmed to: decrypt the command using a symmetric key and identify the ESN of the target ECU from the decrypted command.

[0042] According to one embodiment, the gateway is further programmed to: in response to verifying that the ESN of the target ECU is not included in the trust network, send a trust request to a plurality of subnets of the vehicle; receive a trust response from the target ECU via one of the subnets; and verify that the target ECU is trustworthy based on the trust response.

[0043] According to one embodiment, the gateway is further programmed to: verify that the target ECU is trustworthy by confirming that the vehicle identification number (VIN) of the vehicle is included in the trust response.

[0044] According to one embodiment, the gateway is further programmed to: verify that the target ECU is trustworthy by confirming that the trust response is successfully decrypted by the gateway.

[0045] According to one embodiment, the gateway is further programmed to: in response to successfully verifying that the target ECU is trustworthy, add the ESN of the target ECU to the trust network.

[0046] According to one embodiment, the gateway is further programmed to: in the trust network, indicate the subnet in which the target ECU is located in the subnet as the subnet on which the trust response is received.

[0047] According to the present invention, there is provided a method for verifying whether an electronic serial number (ESN) of a target ECU of a received command is included in a trust network stored in a gateway of a vehicle; if so, forwarding the command to the target ECU; and if not, verifying that the target ECU is trustworthy based on a trust response to a trust request sent by the gateway to a plurality of subnets of the vehicle.

[0048] According to one embodiment, the present invention is further characterized in that: by confirming that the vehicle identification number (VIN) of the vehicle is included in the trust response, it is verified that the target ECU is trustworthy.

[0049] According to one embodiment, the present invention is further characterized in that: by confirming that the trust response is successfully decrypted by the gateway, it is verified that the target ECU is trustworthy.

[0050] According to one embodiment, the present invention is further characterized in that: in response to successfully verifying that the target ECU is trustworthy, the ESN of the target ECU is added to the trust network.

[0051] According to one embodiment, the present invention is further characterized in that: in the trust network, the subnet where the target ECU is located in the subnet is indicated as the subnet on which the trust response is received in the subnet.

[0052] According to one embodiment, the command is a request to unlock the vehicle door, and the target ECU is the body controller of the vehicle.

[0053] A non-transitory computer-readable medium includes instructions that, when executed by a processor of a vehicle gateway, cause the gateway to confirm whether the ESN of the target ECU of the received command is included in the trust network stored in the gateway; if so, forward the command to the target ECU; and if not, verify that the target ECU is trustworthy according to the trust response to the trust requests sent by the gateway to multiple subnets of the vehicle.

[0054] According to one embodiment, the present invention is further characterized in that the instructions, when executed by a processor of the gateway, cause the gateway to verify that the target ECU is trustworthy by confirming that the vehicle identification number (VIN) of the vehicle is included in the trust response.

[0055] According to one embodiment, the present invention is further characterized in that the instructions, when executed by a processor of the gateway, cause the gateway to verify that the target ECU is trustworthy by confirming that the trust response is successfully decrypted by the gateway.

[0056] According to one embodiment, the present invention is further characterized in that the instructions, when executed by a processor of the gateway, cause the gateway to add the ESN of the target ECU to the trust network in response to successfully verifying that the target ECU is trustworthy.

[0057] According to one embodiment, the present invention is further characterized in that the instructions, when executed by a processor of the gateway, cause the gateway to indicate, in the trust network, the subnet where the target ECU is located in the subnet as the subnet on which the trust response is received in the subnet.

Claims

1. A system for processing commands, comprising: A gateway of a vehicle, the gateway being connected to a telematics control unit (TCU) and a plurality of electronic control units (ECUs), the gateway being configured to store a symmetric key for encrypting and decrypting security commands, and the gateway being programmed to: Receive a command from the TCU, the command specifying an electronic serial number (ESN) of a target ECU among the ECUs; In response to confirming that the ESN of the target ECU is not included in a trust network stored in the gateway, send a trust request to a plurality of subnets of the vehicle; Receive a trust response from the target ECU via one of the subnets, the trust response including the ESN encrypted using a symmetric key known to the gateway and a pre-computed version of a vehicle identification number (VIN) of the vehicle, the target ECU lacking the ability to store keys; Verify that the target ECU is trustworthy at least by decrypting the trust response using the symmetric key; And In response to confirming that the ESN of the target ECU is included in the trust network, forward the command to the target ECU.

2. The system according to claim 1, wherein, The gateway is further programmed to: Decrypt the command using a symmetric key; and Identify the ESN of the target ECU from the decrypted command.

3. The system according to claim 1, wherein The gateway is further programmed to: verify that the target ECU is trustworthy by confirming that the VIN is included in the trust response.

4. The system according to claim 1, wherein The gateway is further programmed to: verify that the target ECU is trustworthy by confirming that the trust response is successfully decrypted by the gateway.

5. The system according to claim 1, wherein The gateway is further programmed to: in response to successfully verifying that the target ECU is trustworthy, add the ESN of the target ECU to the trust network.

6. The system according to claim 5, wherein The gateway is further programmed to: in the trust network, indicate the subnet in which the target ECU is located in the subnet as the subnet on which the trust response is received.

7. A method for processing commands, comprising: Confirming, by a gateway of a vehicle, whether an ESN of a target ECU of a received command is included in a trust network stored in the gateway, the gateway being configured to store a symmetric key for encrypting and decrypting security commands; In response to the ESN being included in the trust network, forwarding the command to the target ECU; And In response to the ESN not being included in the trust network, performing the following: Sending a trust request to a plurality of subnets of the vehicle; Receiving a trust response from the target ECU via one of the subnets, the trust response including the ESN encrypted using a symmetric key known to the gateway and a pre-computed version of a vehicle identification number (VIN) of the vehicle, the target ECU lacking the ability to store keys; And Verifying that the target ECU is trustworthy at least by decrypting the trust response using the symmetric key.

8. The method according to claim 7, the method further comprising verifying that the target ECU is trustworthy by confirming that the VIN is included in the trust response.

9. The method according to claim 7, the method further comprising verifying that the target ECU is trustworthy by confirming that the trust response is successfully decrypted by the gateway.

10. The method according to claim 7, the method further comprising adding the ESN of the target ECU to the trust network in response to successfully verifying that the target ECU is trustworthy.

11. The method according to claim 7, the method further comprising indicating, in the trust network, the subnet in which the target ECU in the subnet is located as the subnet on which the trust response is received in the subnet.

12. The method according to claim 7, wherein, The command is a request to unlock the vehicle door, and the target ECU is the body controller of the vehicle.

13. The method according to claim 7, the method further comprising: receiving the command from an in-vehicle information control unit connected to the gateway, the command specifying the electronic serial number ESN of a target ECU among the ECUs; using a symmetric key to decrypt the command; and identifying the ESN of the target ECU from the decrypted command.

14. A non-transitory computer-readable medium, when instructions included in the non-transitory computer-readable medium are executed by a processor of a vehicle gateway, causing the processor to execute the method for processing a command according to any one of claims 7 to 13.

15. A computer program product, the computer program product comprising computer programs / instructions which, when executed by a processor, implement the method for processing a command according to any one of claims 7 to 13.

Images