Safety car system

Abstract

A method, electronic control unit (ECU), and a secure automotive system are disclosed. The method includes the step of calculating an encryption value of one or more or all modules of an ECU. The ECU is classified according to a cyber assurance level (CAL). Further, the encryption value is compared to a stored encryption value. Thereafter, based on the CAL classification of the ECU, one of the following steps is performed: providing control to the one or more or all modules of the ECU when the encryption value matches the stored encryption value; and shutting down the ECU in one of a current boot cycle or a subsequent boot cycle when the encryption value does not match the stored encryption value.

Description

TECHNICAL FIELD

[0001] The present invention relates generally to automotive systems. In particular, but not exclusively, the present invention relates to a method and apparatus for securing an automotive system and a system. BACKGROUND

[0002] The automotive industry is growing rapidly and traditional mechanical controls are now being replaced by electronic controls driven by software code. Modern vehicles are connected to various systems for controlling, monitoring and analyzing vehicle parameters. Vehicle systems are controlled by multiple controllers, commonly known as electronic control units (ECUs). Modern vehicles include different types of ECUs, such as body control units (BCUs), vehicle control units (VCUs), and the like. Each ECU has a dedicated function. Typically, ECUs communicate with other ECUs to operate the vehicle. ECUs host one or more software applications and firmware.

[0003] As modern vehicles are connected to the internet and communicate with external infrastructure and other vehicles, vehicle ECUs are vulnerable to cyber attacks. A common way to attack vehicle ECUs is by means of malicious applications or via firmware updates. Therefore, there is a need to detect cyber attacks and take effective action when a cyber attack is detected.

[0004] The information disclosed in the Background section of the disclosure is only for the purpose of enhancing the understanding of the general background of the invention and should not be considered as admitting or in any form suggesting that this information forms the prior art known to those skilled in the art. SUMMARY

[0005] Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed disclosure.

[0006] In one embodiment, a method, an electronic control unit (ECU) and a secure automotive system are disclosed. The method comprises the step of calculating an encryption value of one or more or all modules of the ECU. The ECU is classified according to a cyber security assurance level (CAL). Further, the encryption value is compared with a stored encryption value. Thereafter, based on the CAL classification of the ECU, one of the following steps is performed: providing control to the one or more or all modules of the ECU when the encryption value matches the stored encryption value; and shutting down the ECU in one of a current boot cycle or a subsequent boot cycle when the encryption value does not match the stored encryption value.

[0007] In one embodiment, the encryption value is a message authentication code (MAC).

[0008] In one embodiment, the cryptographic value of the one or more or all modules is computed based on at least one of a length of code of the one or more or all modules and a starting address and an ending address of code of the one or more or all modules.

[0009] In one embodiment, the one or more or all modules include at least one of a boot manager, a bootloader, and an application.

[0010] In one embodiment, shutting down the ECU includes the steps of determining a CAL of the ECU, shutting down the ECU in a current boot cycle when the ECU is classified as CAL 4 and / or CAL 3, and shutting down the ECU in a subsequent boot cycle when the ECU is classified as CAL 2 and / or CAL 1.

[0011] In one embodiment, shutting down the ECU in the subsequent boot cycle includes providing control to the one or more or all modules of the ECU in the current boot cycle after determining that the cryptographic value does not match the stored cryptographic value.

[0012] In one embodiment, shutting down the ECU further includes recording a failure of the ECU in a memory.

[0013] In one embodiment, the method includes securing access to the ECU using a public key infrastructure (PKI).

[0014] In one embodiment, securing access to the ECU includes storing a root certificate including a root public key in the ECU, generating and sending a challenge to a device upon receiving a request from the device to access the ECU, receiving a response to the challenge including a device signature and a device certificate, wherein the device signature is generated by signing an encrypted value of the challenge using a device private key, and wherein the device certificate is generated using a root private key, authenticating the device by verifying the device certificate using the root public key, and verifying the signature using a public key obtained from the device certificate, wherein the device is allowed to access the one or more ECUs upon successful verification.

[0015] The above summary is illustrative only and is not intended to be limiting in any way. Still other aspects, embodiments and features relating to the aspects can be apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0016] The novel features and attributes of the present application are set forth with particularity in the appended claims. The present application itself, however, both as to its organization and manner of operation, together with its preferred modes of use, further objects and advantages thereof, can best be understood by reference to the following detailed description of illustrative embodiments, taken in conjunction with the accompanying drawings described below. The accompanying drawings incorporated in and forming a part of the specification, illustrate several aspects of the present application and, together with the description, serve to explain the principles of the disclosed concepts. In the drawings, the leftmost digit(s) of reference numbers identify the figure in which that reference numeral first appears. One or more embodiments are now described, by way of example only, with reference to the accompanying drawings in which:

[0017] Figure 1 A simplified diagram of a vehicle network is shown in accordance with some embodiments of the present application;

[0018] Figure 2 A simplified diagram of an ECU is shown in accordance with some embodiments of the present application;

[0019] Figure 3 An exemplary architecture of an internal element HSM is shown in accordance with some embodiments of the present application; and

[0020] Figure 4 An exemplary flowchart illustrating method steps for protecting an automotive system is shown in accordance with some embodiments of the present application;

[0021] Figure 5 An exemplary flowchart illustrating method steps for shutting down an ECU on condition is shown in accordance with embodiments of the present application.

[0022] Figure 6 A security message flow between an ECU and external systems is shown in accordance with some embodiments of the present application; and

[0023] Figure 7 A diagram of an automotive system in accordance with some embodiments of the present application.

[0024] Those skilled in the art will appreciate that any flowchart, flow diagram, state transition diagram, pseudocode, and the like represent various processes which can be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. DETAILED DESCRIPTION

[0025] In this document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any implementation of the subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

[0026] While the present invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the description herein of specific embodiments is not intended to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention.

[0027] The terms "comprise", "comprising", "contain", "containing", "include", "including" and "includes" or any other variation thereof are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but can include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or device are not more restrictive than "comprising... A" or "comprising... A" before them, excluding the presence of other elements or additional elements in the system or device.

[0028] In the following detailed description of embodiments of the application, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the application can be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the application, and it is to be understood that other embodiments can be utilized and that changes can be made without departing from the scope of the present application. The following description is, therefore, not to be taken in a limiting sense.

[0029] Figure 1An architecture of a vehicle network is shown. The vehicle 101 comprises a plurality of electronic control units (ECUs) 102a, 103b, 102g. Each ECU is configured to perform one or more functions. For example, the ECU 102a can be configured to control an anti-lock braking system (ABS) of the vehicle 101, and the ECU 102b can be configured to control an infotainment system of the vehicle 101. Further, each ECU is classified according to a cybersecurity assurance level (CAL). In one embodiment, the CALs are defined in accordance with ISO / SAS 31434. An ECU classified as CAL-4 has the highest cybersecurity assurance. For example, the ECU 102a can be configured to control an advanced driver assistance (ADAS) function. The ADAS function is safety critical, and the ECU 102a performing the ADAS function is classified under the highest safety level. Thus, the ECU 102 performing the ADAS function needs to be protected with the highest assurance and is classified as CAL-4, likewise, an ECU 102 configured to perform functions such as ABS, airbag can be classified as CAL-4, further, an ECU 102 configured to perform functions such as engine management, suspension can be classified as CAL-3, likewise, an ECU 102 configured to perform functions such as light control, operating instrument cluster, operating infotainment system, cruise control can be classified as CAL-2 and / or CAL-1.

[0030] In one embodiment, the plurality of ECUs 102a, 103b, 102g can communicate with each other via a communication line such as a controller area network (CAN), CANFD, FlexRay, local interconnect (LIN), and the like. In one embodiment, the vehicle network is built in an electrical / electronic (E / E) architecture. An ECU 102 can be attacked by tampering a flash file and sending the tampered flash file for ECU update. When the ECU 102 executes the tampered flash file, the ECU 102 is disabled or controlled by the attacker. Thus, the ECU 102 needs to detect a cyber attack.

[0031] Figure 2 A simplified diagram of an ECU 102 of an automotive system in accordance with some embodiments of the present application is shown.

[0032] The ECU 102 comprises a hardware security module (HSM) 201, a boot manager 202, a bootloader 203, a kernel 204, a root file system 205, and a plurality of applications 206a, 206b, 206g. The HSM 201 is configured to protect the boot manager 202, the bootloader 203, the kernel 204, the root file system 205, and the plurality of applications 206a, 206b, 206g from a cyber attack.

[0033] 203, one or more applications 204 and interfaces 205. The boot manager 202 is a boot application stored in a read-only memory (ROM) of the ECU 102. The boot manager 202 is configured to boot firmware also stored in the ROM during each boot sequence of the ECU 102. The boot manager 202 is further configured to check for firmware updates and, if firmware updates are available, to initiate a firmware download. Furthermore, the boot manager 202 is configured to provide control to the bootloader 203 to execute the firmware.

[0034] The bootloader 203 is configured to boot the firmware selected by the boot manager 202. The bootloader executes the firmware present in the ROM. Once the firmware is executed, the bootloader 203 then executes one or more applications 204 present in the ECU 102.

[0035] The one or more applications 204 can include airbag deployment applications, ADAS applications, light control applications, infotainment control applications, etc.

[0036] The interfaces 205 can include CAN interfaces, CAN FD interfaces, LIN interfaces, FLexRay interfaces, etc. The interfaces 205 enable the ECU 102 to connect to an in-vehicle network. The in-vehicle network is accessed by a plurality of ECUs 102a, 102b,..., 102g. Data is exchanged between the plurality of ECUs 102a, 102b,..., 102g and / or between the ECU 102 and one or more sensors or actuators of the vehicle 101.

[0037] The HSM 201 can be a hardware or software component present in the ECU 102 that provides security against cyber attacks. The HSM 201 is configured to generate and store cryptographic keys, certificates, provide secure hash functions. The HSM 201 supports secure flash programming and reprogramming.

[0038] In one embodiment, the ECU 102 includes one or more processors or controllers (not shown) and memory (RAM, ROM). The ECU 102 can also include a storage memory.

[0039] Figure 3A simplified block diagram of the HSM 201 is shown. The HSM 201 includes a random number generator (RNG) 301, a cryptographic generator 302, a boot message authentication code (MAC) 303, a root public key 304, a bus interface 305, a comparator 306, and a host interface 307. The host interface 307 is configured with a memory mapped register that is used by one or more processors or controllers of the ECU 102 to issue commands. The bus interface 305 allows the HSM 201 to access the memory of the ECU 102. The HSM 201 can include secure memory for storing cryptographic keys and cryptographic values. For example, the HSM 201 can include 20 memory slots with one ROM slot and 15 non-volatile slots and one RAM slot. The secure memory stores the boot MAC value, the root public key, and optionally a master key. The boot MAC value can be unique to the module for which the HSM is designed. For example, each module 202, 203, 204, 205 has its own HSM 201, or a single HSM 201 can operate with each module 202, 203, 204, 205. In one embodiment, different types of MACs can be generated. For example, HMAC, CMAC, KMAC.

[0040] In one embodiment, a plurality of flags can be provided. Each flag is associated with a specific indication and action. For example, a secure boot flag is set (explained in further detail) when the MAC value of the firmware does not match the stored MAC value. Further, a key flag is set when the key is used to generate the MAC value and is reset when the key is used for verification. The HSM 201 can be configured to support the AES encryption and decryption standard. The HSM 201 can use the AES- 128 MAC algorithm for message authentication. The key for the MAC operation is selected from the memory slots. The MAC algorithm uses the key and a -n arbitrary length message to be authenticated and outputs a MAC value as an encrypted value. The MAC value protects the integrity and authenticity. The RNG 301 can be used to generate the key. For example, the RNG 301 can generate a 128-bit key for generating the MAC. The arbitrary length value can be a start address and end address value of one or more modules 202, 203, 204, 205. For example, consider an application 204 that must be protected. When stored in the ECU 102, the application 204 has a start address value and an end address value. The password generator 302 can execute the MAC algorithm by taking the start address and end address values of the application 204 and the key generated by the RNG 301 and generate a unique MAC value for the application 204. The MAC value generated for the application 204 is stored in a dedicated memory slot. Further, when the ECU 102 is powered on and when the application 204 is initialized for execution, the HSM 201 determines the authenticity and integrity of the application 204. The HSM 201 obtains the start address and end address values of the application 204 via the bus interface 305. Further, the start address and end address values are provided to the password generator 302, which generates the MAC value. The calculated MAC value is then compared to the stored MAC value in the comparator 306. When the calculated MAC value matches the stored MAC value, the application 204 is determined to be authentic and is allowed to execute. When the calculated MAC value does not match the stored MAC value, an appropriate action is performed. Likewise, the HSM 201 is also configured to the boot manager 202 and the bootloader 203. A MAC value is generated and stored for the boot manager 202. At each boot, a new MAC value is calculated for the boot manager 202. When there is a match, control is provided to the boot manager 202, where the boot manager 202 performs its functions. Further, when the boot manager 202 selects the firmware and initializes the bootloader 203, a MAC value is calculated for the bootloader 203 and compared to the stored MAC value. When there is a match, control is provided to the bootloader 203 to run the firmware and when there is no match, an appropriate action is performed. In one embodiment, the appropriate action includes shutting down the ECU 102 in one of the current boot cycle or a subsequent boot cycle based on the CAL classification of the ECU 102.

[0041] In an embodiment, the host interface 307 can set a bit for successful authentication and reset a bit for unsuccessful authentication. In another embodiment, the bit value of the host interface 307 can be inverted to indicate successful and unsuccessful authentication. Further, the bit value is provided to one or more modules 202, 203, 204. The bit value can also be provided to the power controller of the ECU 102 for shutting down the ECU 102 based on the bit value of the host interface 307.

[0042] In one embodiment, when the computed CAMV value does not match the stored MAC value, the ECU 102 is shut down based on certain conditions. The HSM 201 determines the CAL classification of the ECU 102. When the ECU 102 is classified as CAL-4 and / or CAL-3, the ECU 102 can be shut down in the current boot cycle. As mentioned earlier, CAL-4 and CAL-3 classified ECUs perform safety critical functions and a mismatch between the computed MAC value and the stored MAC value indicates that the safety critical ECU is compromised. Therefore, such ECUs are shut down in the current boot cycle to prevent further harm to the vehicle 101 and the occupants. In one embodiment, when the ECU 102 is classified as CAL-2 and / or CAL-1, the ECU 102 can be shut down in the subsequent boot cycle. Since CAL-2 and CAL-1 are not associated with safety critical functions, the ECUs classified under these CAL categories can be shut down in the subsequent boot cycle. However, the present application is not limited to shutting down the ECU 102 classified as CAL-2 and / or CAL-1 in the subsequent boot cycle, and such ECUs 102 can also be shut down in the current boot cycle.

[0043] In one embodiment, when the HSM 201 is configured to shut down the ECU 102 in the subsequent boot cycle, one or more or all modules 202, 203, 204 are provided control to perform the respective functions in the current boot cycle. For example, when it is determined that the light control application has been attacked, the ECU 102 comprising the light control application is configured to be shut down in the subsequent boot cycle. However, the light control application can be provided control to operate the lights of the vehicle 101 in the current boot cycle. Since the functions of the CAL-2 and CAL-1 ECUs are not safety critical, the ECUs can still function despite the attack on them since they can not pose a threat. Further, when an intrusion is detected, a fault is logged in the memory of the HSM 201. Details related to the fault, such as date, time, module name, ECU ID, CAL type, etc. can also be included in the log. Further, the fault log can also be communicated to a remote center for analysis. The remote center can analyze the fault log and develop a patch / firmware update. The firmware update can be released to the fleet of vehicles.

[0044] In one embodiment, the ECU 102 can communicate with a remote center via a communication channel such as 5G / LTE, etc. However, the communication via such channels also poses a threat to the ECU 102. Therefore, the present invention proposes the use of Public Key Infrastructure (PKI) technology for secure access to the ECU 102. The PKI technology uses a key pair for authenticating entities communicating with the ECU 102. The working of the PKI technology is explained in further detail.

[0045] Figure 4 A flow diagram illustrating a method for securing an automotive system is shown in accordance with some embodiments of the present invention. The order in which a method 400 is described is not to be construed as a limitation, and any number or combination of the method blocks can be combined in any order to implement the method. Additionally, individual blocks can be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0046] At step 401, a cryptographic value of one or more or all modules 202, 203, 204 of the ECU 102 is computed. In one embodiment, the computation of the cryptographic value or MAC value is performed at every boot cycle. The MAC value can also be computed at a defined time period when the ECU 102 has not been restarted for a long time. For example, when an infotainment application is running for ten hours, and when the ECU 102 hosting / holding the infotainment application has not been restarted for ten hours, the MAC value can be computed for verification after ten hours. As mentioned above, the ECU 102 is classified based on the CAL.

[0047] At step 402, the MAC value is compared with a stored MAC value. The stored MAC value can be generated during manufacturing or by an original equipment manufacturer (OEM). For example, when the ECU 102 is manufactured, MAC values for the boot manager 202, the bootloader 203, and one or more library applications 204 can be generated and stored in the respective or common HSM 201. In one embodiment, MAC values for third party applications can also be generated when such applications are deployed in the ECU. In one embodiment, the MAC values are generated using a start address value and an end address value of the one or more modules 202, 203, 204. However, the MAC value generation is not limited to using the start and end address values, and other information related to the one or more modules 202, 203, 204 can also be considered. Further, a new MAC value is computed for the one or more modules 202, 203, 204 during each boot cycle or after a defined period of time, and the new MAC value is compared with the stored MAC value. A successful match in the comparison indicates that the ECU 102 is not compromised by malicious code. An unsuccessful match indicates that the ECU 102 has been compromised.

[0048] Step 403 is performed when the comparison of step 402 is successful. At step 403, the one or more modules 202, 203, 204 are provided control to perform respective functions. For example, when the MAC value of the boot manager 202 matches the stored MAC value of the boot manager 202, the boot manager 202 is provided control to initiate a boot sequence of the ECU 102. Likewise, when the MAC value of the bootloader 203 matches the stored MAC value of the bootloader 203, the bootloader 203 is provided control to load firmware of the ECU 102.

[0049] Step 404 is performed when the comparison of step 402 is unsuccessful. At step 404, the ECU 102 is shut down in the current boot cycle or a subsequent boot cycle based on the CAL classification of the ECU 102. Reference is now made to FIG. 4B, which illustrates a flowchart of a method 400B for shutting down the ECU 102 in the current boot cycle or a subsequent boot cycle based on the CAL classification of the ECU 102. Figure 5which shows the shutdown procedure of the ECU 102. At step 501, the CAL classification of the ECU 102 is determined. The ECU 102 can be classified as one or two CALs. For example, the ECU 102 can be classified as CAL-4 and CAL-3, the ECU 102 can have very high safety-critical and medium safety-critical functions. Thus, the ECU 102 can be classified as two CAL categories. At step 502, the ECU 102 is shut down in the current boot cycle when the ECU 102 is classified as CAL-4 and / or CAL-3. The ECU 102 is shut down immediately (current boot cycle) when the ECU 102 classified as CAL-4 and / or CAL-3 performs safety-critical functions. At step 503, the ECU 102 is shut down in the subsequent boot cycle when the ECU 102 is classified as CAL-2 and / or CAL-1.

[0050] In one embodiment, when the ECU 102 is shut down in the subsequent boot cycle, one or more or all of the modules 202, 203, 204 are provided control to perform the respective functions in the current boot cycle. Further, the failure of the ECU 102 is recorded in the memory of the HSM 201 and such failure data is sent to a remote center for analysis. The remote center can analyze and issue a patch or firmware / software update to the ECU 102 and send the update back to the ECU 102 via the communication channel. To ensure access to the ECU 102 by external agents such as the remote center, PKI technology is employed.

[0051] Figure 6 Exemplary PKI technology for securing access to the ECU 102 is shown. In one embodiment, Figure 6A challenge-response method is specifically shown. The challenge-response method is based on a PKI architecture. The PKI architecture includes a trusted entity or certificate authority 601, an external entity or remote center 602, and a device or ECU 102 to be protected. The remote center 602 can be a developer or test facility associated with the OEM. The trusted entity or certificate authority 601 can be a facility that issues certificates (TSL or SSL certificates). The trusted entity 601 can use its private key to generate a root certificate and include the root public key in the certificate. The certificate including the root public key is stored in the ECU 102 (preferably in the HSM 201). In addition, the certificate also mentions that the trusted entity 601 has been verified as a true source. When the remote center 602 has to establish communication with the ECU 102, the integrity and authenticity of the remote center 602 has to be verified. This can be done using a challenge-response technique. The remote center 602 sends a request message 610 requesting a challenge to the ECU 102. The ECU 102 generates 612 the challenge. In one embodiment, the challenge can be a random number generated using the RNG 301. In addition, the ECU 102 sends 614 the challenge to the remote center 602. The remote center 602 then forwards 616 the received challenge to the trusted entity 601. The trusted entity 601 verifies the remote center 602 and generates 618 a response to the challenge. The response to the challenge includes a hash value of the challenge and a certificate. The hash value of the challenge is signed using the private key of the remote center 602 and the corresponding public key is encapsulated in the certificate. In one embodiment, the key pair (private and public keys of the remote center 602) is generated by the trusted entity 601. In addition, the response is sent 620 to the remote center 602 which in turn forwards 622 the response to the ECU 102. The ECU 102 uses the root public key stored in the HSM 201 to verify 624 the authenticity of the response. When the authenticity is verified, the integrity is verified by decrypting the tag using the public key of the remote center 602. When the authenticity and integrity are verified, the remote center is allowed to communicate with the ECU 102. Thus, the access to the ECU 102 is always secure.

[0052] Figure 7An exemplary automotive system 700 is shown. The automotive system 700 comprises a plurality of ECUs 102a, 102b, a gateway device 702, and a communication control unit (CCU) 701. In one embodiment, the plurality of ECUs 102a, 102b communicate with each other via a secure in-vehicle communication network. By implementing a MAC value of a protocol data unit (PDU) sent by each ECU, the security of the vehicle communication network can be ensured. Furthermore, freshness values and intrusions in the vehicle communication network that are truncated to the MAC value that ensures secure communication between the ECUs can be detected. Moreover, the gateway device 702 protects the ECU network of the vehicle by implementing rules and separating domains. Furthermore, the communication of the vehicle 102 with external entities such as other vehicles and remote centers is protected when routing the communication via the CCU 701 and using a challenge-response method. Moreover, the integrity of firmware updates can also be verified using the MAC value of the flash driver. Thus, the vehicle architecture is divided into four levels 710, 712, 714, 716, which ensures a secure automotive system 700.

[0053] The terms "embodiment," "embodiments," "the embodiment," "the embodiments," "one or more embodiments," "some embodiments,” and "one embodiment" mean “one or more (but not all) embodiments of the invention,” unless expressly specified otherwise.

[0054] The terms “comprise,” “comprising,” “have,” “having,” “include,” “including,” and “contain,” “containing,” or variations thereof, mean “including, but not limited to,” unless expressly specified otherwise.

[0055] Unless expressly specified otherwise, an enumerated list of items does not imply that any or all of the items are mutually exclusive. The terms “a,” “an,” and “the” mean “one or more,” unless expressly specified otherwise.

[0056] The description of an embodiment having several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate various potential embodiments of the present invention.

[0057] When a single device or article is described herein, it will be readily apparent that more than one device / article (whether or not they cooperate) can be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device / article can be used in place of the more than one device or article or a different number of devices / articles can be used instead of the shown number of devices or programs. The functionality and / or the features of a device can be alternatively embodied by one or more other devices which are not explicitly described as having such functionality / features. Thus, other embodiments of the invention need not include the device itself.

[0058] Figure 4 and Figure 5 The illustrated operations of FIGS. 1 through 7 show certain events occurring in a certain order. In alternative embodiments, certain operations can be performed in a different order, modified or removed. Moreover, steps can be added to the above-described logic and still conform to the described embodiments. Further, operations described herein can occur sequentially or certain operations can be processed in parallel. Moreover, operations can be performed by a single processing unit or by distributed processing units.

[0059] Finally, the language used in the specification has been principally selected for readability and instructional purposes and it can not have been selected to delineate or circumscribe the subject application. Accordingly, the scope of the subject application is indicated by the following claims, rather than the foregoing description, and all changes that come within the meaning and range of equivalents are intended to be embraced therein. The disclosure of the embodiments of the application is intended to be illustrative, and not to limit the scope of the application. The scope of the subject application is thus indicated by the following claims.

[0060] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to limit the scope of the application, which is set forth in the following claims.

Claims

1. A computer-implemented method for protecting an automotive system (700), characterized in that, include: Calculate the encrypted values ​​of one or more modules (202, 203, 204) of the electronic control unit (ECU) (102) for the automotive system (700), wherein the ECU (102) is classified according to the cybersecurity assurance level (CAL); Compare the encrypted value with the stored encrypted value; and Based on CAL classification, perform one of the following steps: When the encrypted value matches the stored encrypted value, control is provided to one or more modules (202, 203, 204); or When the encrypted value does not match the stored encrypted value, the ECU (102) is shut down in either the current boot cycle or a subsequent boot cycle. The encrypted value for the one or more modules (202, 203, 204) is calculated based on at least one of the length of the code of the one or more modules (202, 203, 204) and the start address and end address of the code of the one or more modules (202, 203, 204).

2. The method according to claim 1, wherein, The encrypted value is a Message Authentication Code (MAC).

3. The method according to claim 1 or 2, wherein, The one or more modules (202, 203, 204) include at least one of the boot manager (202), the boot loader (203), and the application (204).

4. The method according to claim 1 or 2, wherein, Shutting down the ECU (102) includes: Determine the CAL of the ECU (102); When the ECU (102) is classified as CAL-4 and / or CAL-3, the ECU (102) is shut down during the current boot cycle; and When the ECU (102) is classified as CAL-2 and / or CAL-1, the ECU (102) is shut down in a subsequent boot cycle.

5. The method according to claim 1 or 2, wherein, Disabling the ECU (120) in a subsequent boot cycle includes: After determining that the encrypted value does not match the stored encrypted value, control is provided to one or more or all modules (202, 203, 204) of the ECU (102) during the current boot cycle.

6. The method according to claim 1 or 2, wherein, Shutting down the ECU (102) also includes: The fault of the ECU (102) is recorded in the memory.

7. The method according to claim 1 or 2 further includes using public key infrastructure (PKI) to protect access to the ECU (102).

8. The method according to claim 7, wherein, Protecting access to the ECU (120) includes: Store the root certificate, including the root public key, in the ECU (102). When a request to access ECU (102) is received from device (602), Generate and send a challenge to the device (602); Receive a response to the challenge, the response including a device signature and a device certificate, wherein the device signature is generated by signing the encrypted value of the challenge using a device private key, and wherein the device certificate is generated using a root private key; The device is authenticated by verifying the device certificate using the root public key (602); and The signature is verified using the public key obtained from the device certificate, wherein, upon successful verification, the device (602) is allowed to access the ECU (102).

9. An electronic control unit (ECU) (102), comprising: Hardware Security Module (HSM) (201); Boot manager (202); Bootloader (203); and One or more applications (204) Its features are, The HSM (201) is configured as follows: Calculate the encrypted values ​​for one or more modules (202, 203, 204) of the ECU (102), wherein the ECU (102) is classified according to the Cybersecurity Assurance Level (CAL); Compare the encrypted value with the stored encrypted value; and Based on CAL classification, perform one of the following steps: When the encrypted value matches the stored encrypted value, control is provided to one or more modules (202, 203, 204); or When the encrypted value based on the CAL classification does not match the stored encrypted value, the ECU is shut down in either the current boot cycle or a subsequent boot cycle (102). The HSM (201) is configured to calculate the encrypted value for the one or more modules (202, 203, 204) based on at least one of the length of the code of the one or more modules (202, 203, 204), the start address and the end address of the code of the one or more modules (202, 203, 204).

10. The ECU (102) according to claim 9, wherein, The HSM (201) is configured to calculate the Message Authentication Code (MAC) as an encrypted value.

11. The ECU according to claim 9 or 10, wherein, The HSM (201) is configured to shut down the ECU (102), wherein the HSM (201) is configured to: Determine the CAL (102) of the ECU; When the ECU (102) is classified as CAL-4 and / or CAL-3, the ECU (120) is shut down during the current boot cycle. as well as When the ECU is classified as CAL-2 and / or CAL-1, the ECU is shut down in a subsequent boot cycle (120).

12. The ECU (102) according to claim 9 or 10, wherein, The HSM (201) is configured to shut down the ECU (102) in a subsequent boot cycle, wherein the HSM (201) is further configured to: After determining that the encrypted value does not match the stored encrypted value, control is provided to one or more or all modules (202, 203, 204) of the ECU (102) during the current boot cycle.

13. The ECU (102) according to claim 9 or 10, wherein, The HSM (201) is configured to shut down the ECU (102), wherein the HSM (201) is further configured to: The fault of ECU (102) is recorded in the memory.

14. The ECU (102) according to claim 9 or 10, wherein, The HSM (201) is also configured to use public key infrastructure (PKI) to protect access to the ECU (102).

15. The ECU (102) according to claim 14, wherein, The HSM (201) is configured to protect access to the ECU (102), wherein the HSM (201) is further configured to: The root certificate, including the root public key, is stored in the ECU (102); When a request for access to ECU (102) is received from the device, Generate and send a challenge to the device (602); Receive a response to the challenge, the response including a device signature and a device certificate, wherein the device signature is generated by signing the encrypted value of the challenge using a device private key, and wherein the device certificate is generated using a root private key; The device is authenticated by verifying the device certificate using the root public key (602); and The signature is verified using the public key obtained from the device certificate, wherein, upon successful verification, the device (602) is allowed to access the ECU (102).

16. An automotive system (700) comprising: A plurality of electronic control units (ECUs), wherein at least one ECU is an ECU according to any one of claims 9 to 15; Gateway (702); as well as Communication control unit (CCU) (701).

Images