Method and system for verifying vehicle security - Patents.com

Abstract

The disclosed subject matter relates to the field of cryptography and vehicle security, providing a method for verifying the security of a vehicle. An authentication system integrated into a zone master ECU of a given zone requests pre-assigned signed unique cryptographic key shares from each of multiple primary ECUs associated with the zone master ECU when an authentication request is present. The authentication system may then use a pre-defined number of key shares to calculate a first unique signature for the given zone and use a public key to verify the validity of the calculated first unique signature. Finally, the verified first unique signature is provided to a vehicle master ECU associated with the zone master ECU, allowing it to activate a safety function associated with the primary ECU. The same method is then repeated for multiple secondary ECUs. The present disclosure allows for achieving a fast, non-sequential, single-step verification of the security of a vehicle.

Description

[Technical field]

[0001] The present subject matter relates generally to the field of cryptography and vehicle security, and more particularly, but not exclusively, to methods and systems for verifying the security of a vehicle. [Background technology]

[0002] Nowadays, vehicles have a number of electronic control units (ECUs) that form an in-vehicle network. These ECUs can be classified into one of critical ECUs and non-critical ECUs based on their functionality and customized definitions provided by the original equipment manufacturers (OEMs). For example, the ECUs that control the vehicle's critical functions, such as safety and security functions, anti-lock braking system (ABS) functions, powertrain functions, surround view and warning functions, gateway functions, etc., can be considered as critical ECUs, and the remaining ECUs that control the vehicle's other non-critical functions, such as infotainment system functions, heating, ventilation and air conditioning (HVAC) control functions, power window control functions, etc., can be considered as non-critical ECUs. During the vehicle startup phase, the ECUs present in the vehicle require security validation to ensure the authenticity of the ECUs in the in-vehicle network. In other words, the security validation can identify whether the critical ECUs of the vehicle have been manipulated by a third party attacker / hacker. If the critical ECUs have been manipulated by a third party attacker / hacker, the vehicle will be under the control of the third party attacker / hacker after the vehicle startup phase. Therefore, verifying the authenticity of ECUs, at least the critical ECUs, during the start-up phase is not only essential but extremely important.

[0003] Existing approaches apply security signatures and security verifications to check the authenticity of ECUs, which are performed sequentially, thereby taking longer time for security verification and thus causing delays during the startup phase beyond the minimum startup time. This may degrade the user experience level. Also, such a sequential approach that takes a long time to perform security verification leads to low coverage of ECUs that need to be verified in the minimum startup time. Such low coverage may lead to missing security verification of critical ECUs during the startup phase, which may lead to significant security issues.

[0004] Currently, existing approaches do not provide a mechanism for non-sequential security verification, which potentially reduces verification time and improves coverage of ECs during security verification.

[0005] The information disclosed in the Background section of this disclosure is merely intended to enhance understanding of the general background of the present disclosure and should not be construed as an admission or any form of suggestion that this information forms prior art already known to those skilled in the art. Summary of the Invention [Means for solving the problem]

[0006] Disclosed herein is a method for verifying security of a vehicle. An in-vehicle network of the vehicle is divided into predefined zones, and each of the predefined zones includes a plurality of ECUs classified as at least one of a primary ECU and a secondary ECU. Each predefined zone includes a zone master ECU associated with each of the plurality of ECUs of the corresponding predefined zone. The method includes, by an authentication system integrated in the zone master ECU of the predefined zone, requesting pre-assigned signed unique cryptographic key shares from the plurality of primary ECUs associated with the zone master ECU when an authentication request is present in the in-vehicle network. Thereafter, the method includes calculating a first unique signature for the predefined zone using a predefined number (K-1) of pre-assigned signed unique cryptographic key shares received from the plurality of primary ECUs. Upon calculating the first unique signature for the predefined zone, the method includes verifying the validity of the calculated first unique signature using a public key to authenticate each of the plurality of primary ECUs in the predefined zone. Finally, the method includes providing the verified first unique signature to a vehicle master ECU associated with a zone master ECU for each predetermined zone to enable the vehicle master ECU to activate a safety function associated with each of the multiple primary ECUs for each predetermined zone.

[0007] The present disclosure further discloses an authentication system for verifying security of a vehicle. An in-vehicle network of the vehicle is divided into predefined zones, and each of the predefined zones includes a plurality of ECUs classified as at least one of a primary ECU and a secondary ECU. Each predefined zone includes a zone master ECU associated with each of the plurality of ECUs of the corresponding predefined zone. The authentication system includes a processor and a memory communicatively coupled to the processor. The memory stores processor instructions that, when executed, cause the processor to request pre-assigned signed unique cryptographic key shares from the plurality of primary ECUs associated with the zone master ECU when an authentication request exists in the in-vehicle network. The processor then calculates a first unique signature for the predefined zone using a predefined number (K-1) of pre-assigned signed unique cryptographic key shares received from the plurality of primary ECUs. Upon calculating the first unique signature for the predefined zone, the processor uses a public key to verify the validity of the calculated first unique signature to authenticate each of the plurality of primary ECUs in the predefined zone. Finally, the processor provides the verified first unique signature to a vehicle master ECU associated with the zone master ECU for each predetermined zone to enable the vehicle master ECU to activate safety functions associated with each of the multiple primary ECUs for each predetermined zone.

[0008] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the exemplary aspects, embodiments and features described above, further aspects, embodiments and features will become apparent by reference to the drawings and the following detailed description.

[0009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the drawings, the leftmost digit(s) of a reference number identifies the figure in which that reference number first appears. The same numbers are used throughout the drawings to reference like features and components. Some embodiments of systems and / or methods according to embodiments of the present subject matter will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0010] [Figure 1A] 1 illustrates an example architecture for verifying vehicle security, according to some embodiments of the present disclosure. [Figure 1B] 1 illustrates another example architecture for verifying vehicle security, according to some embodiments of the present disclosure. [Figure 1C] FIG. 1 illustrates a simplified block diagram of an exemplary authentication system for verifying the security of a vehicle, according to some embodiments of the present disclosure. [Figure 2A] FIG. 1 illustrates a detailed block diagram of an exemplary authentication system for verifying the security of a vehicle, according to some embodiments of the present disclosure. [Figure 2B] 1 illustrates an example scenario for verifying vehicle security according to some embodiments of the present disclosure. [Diagram 3] 1 shows a flowchart illustrating a method for verifying security of a vehicle according to some embodiments of the present disclosure. [Figure 4] FIG. 1 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of exemplary systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flowcharts, state diagrams, pseudocode, or the like, may be substantially represented in a computer-readable medium and represent various processes that may be performed by such a computer or processor, whether or not a computer or processor is explicitly depicted.

[0012] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0013] While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are described in detail below, however, it is to be understood that it is not intended to limit the disclosure to the disclosed forms, but on the contrary, the disclosure is intended to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure.

[0014] The terms "comprise", "including", "comprises" or any other variations thereof are intended to cover a non-exclusive inclusion, such that a setup, device or method that includes a list of components or steps does not include only those components or steps, but may include other components or steps that are not expressly listed or inherent to such setup, or device, or method. In other words, one or more elements in a system or apparatus proceeded by "including a" does not, without more constraints, preclude the presence of other or additional elements in the system or method.

[0015] Disclosed herein are methods and systems for verifying the security of a vehicle. In some embodiments, a vehicle includes an in-vehicle network that connects vehicle components such as control units, sensors, mechanical parts, and various systems and subsystems within the vehicle to enable internal communication between the vehicle components. In one embodiment, the in-vehicle network of the vehicle may be divided into zones, and each of the zones may include a plurality of electronic control units (ECUs). In some embodiments, the plurality of ECUs may be classified into primary ECUs and secondary ECUs. In some embodiments, the primary ECUs may be critical ECUs that may perform critical functions of the vehicle, and the secondary ECUs may be non-critical ECUs that may perform non-critical functions of the vehicle. For example, the primary / critical ECUs may perform critical functions of the vehicle such as safety and security functions, anti-lock braking system (ABS) functions, powertrain functions, surround view and warning functions, gateway functions, etc., and the remaining ECUs, i.e., secondary / non-critical ECUs, may perform non-critical functions of the vehicle such as infotainment system functions, heating, ventilation, and air conditioning (HVAC) control functions, power window control functions, etc.

[0016] Further, each given zone of the in-vehicle network may include a zone master ECU associated with each of the plurality of ECUs of the corresponding given zone. Each zone master ECU in the in-vehicle network may be integrated with an authentication system. The present disclosure may be performed only by the zone master ECU integrated with the authentication system. The method is described in the present disclosure from the perspective of one zone master ECU belonging to a given zone in the vehicle. However, this is merely for purposes of illustration and ease of understanding and should not be construed as a limitation of the present disclosure.

[0017] The authentication system may request pre-assigned signed unique encryption key shares from each of the multiple primary ECUs associated with the zone master ECU when an authentication request exists in the in-vehicle network. Upon receiving the pre-assigned signed unique encryption key shares received from the multiple primary ECUs, the authentication system may calculate a first unique signature for the given zone using a predetermined number (K-1) of pre-assigned signed unique encryption key shares received from the multiple primary ECUs. In some embodiments, the predetermined number (K-1) of pre-assigned signed unique encryption key shares may be defined / calculated at the time of vehicle manufacture or at the time of installation of the zone master ECU in each of the given zones. As an example, the predetermined number (K-1) may be 3, which means that the authentication system may calculate a first unique signature for the given zone using only the three pre-assigned signed unique encryption key shares received from the multiple primary ECUs. However, this should not be construed as limiting, as the predetermined number (K-1) may vary and may be dynamically configurable. In some embodiments, the three pre-assigned signed unique encryption key shares selected to compute the first unique signature may be the three pre-assigned signed unique encryption key shares initially received by the ECU. In some other embodiments, the three pre-assigned signed unique encryption key shares selected to compute the first unique signature may be randomly selected from among the received pre-assigned signed unique encryption key shares. In yet other embodiments, the three pre-assigned signed unique encryption key shares selected to compute the first unique signature may be selected based on a rule. For example, the rule may indicate "select the pre-assigned signed unique encryption key shares received from the critical ECU associated with the anti-lock braking system to generate the first unique signature."

[0018] The authentication system may then verify the validity of the calculated first unique signature using the public key of the given zone to authenticate each of the multiple primary ECUs in the corresponding given zone. Upon verification of the first unique signature, the authentication system may provide the verified first unique signature to a vehicle master ECU associated with the zone master ECU of each given zone to enable the vehicle master ECU to activate a safety function associated with each of the multiple primary ECUs of each given zone. Having initially verified the multiple primary ECUs, the authentication system may then verify the multiple secondary ECUs using the same methodology as disclosed above for the multiple primary ECUs.

[0019] In the present disclosure, the primary ECU (critical ECU) is verified first, followed by the secondary ECU (non-critical ECU). If the critical ECU is attacked by a third party attacker, it may completely compromise the security of the vehicle and hand over the control of the vehicle to the third party attacker. Therefore, authenticating the critical ECU first not only allows checking the authenticity of the most critical ECU of the vehicle with full coverage, but also ensures high security. Moreover, the method disclosed in the present disclosure is not a sequential method of authenticating each ECU of a given zone one after another, rather, the method disclosed in the present disclosure allows parallel verification in each of the given zones and with only a predetermined number (K-1) of key shares received from the primary ECU in each zone. Thus, the present disclosure eliminates the need to wait for a response from each ECU to authenticate that ECU. Rather, the present disclosure allows for the use of (K-1) key shares received from (K-1) number of primary ECUs in a given zone, and authenticates each of the primary ECUs in that zone at once based on the unique signatures calculated using the (K-1) key shares. In the present disclosure, the sequential approach of verification is eliminated, and a parallel approach of verification is performed, i.e., parallel verification in each given zone and also single-step verification in each given zone. Such parallel verification and single-step verification reduces the time taken to verify the authenticity of an ECU, for example, when there is an authentication request during the start-up phase of the vehicle. Moreover, since only (K-1) key shares are used to calculate the first / second unique signatures used for on-shot verification of the ECUs in a given zone, the time required to verify the authenticity is further reduced compared to existing techniques. In addition, in the present disclosure, secondary ECUs are verified for authenticity after the primary ECU due to their non-critical nature. Therefore, verifying the authenticity of the secondary ECU even after the start-up phase, after verifying the primary ECU (which is required for the start-up itself), may not harm the in-vehicle network.Moreover, performing validation of secondary / non-critical ECUs at a later stage after start-up may improve the speed of validation of primary / critical ECUs during the start-up phase, eliminating unnecessary delays during the start-up phase, improving coverage of primary / critical ECUs during the start-up phase, and improving user experience due to faster validation of critical security health checks resulting in a faster start-up.

[0020] A description of an embodiment having several components in communication with each other does not imply that all such components are required, to the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present disclosure.

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

[0022] FIG. 1A illustrates an example architecture for verifying vehicle security according to some embodiments of the present disclosure.

[0023] The in-vehicle network architecture 100 includes a vehicle 101, a vehicle master electronic control unit (ECU) 103, and a predetermined zone 105. 1 ~Prescribed Zone 105 n (collectively referred to as a predetermined zone 105) and a zone master ECU 107 1 ~Zone Master ECU107 n (collectively referred to as zone master ECU 107) and authentication system 109 1 ~Authentication System 109 n (collectively referred to as authentication system 109) and a primary ECU 111 1 ~Primary ECU111 n(collectively referred to as primary ECU 111) and secondary ECU 113 1 ~Secondary ECU113 n(collectively referred to as secondary ECUs 113). In some embodiments, the in-vehicle network may be a network in which various ECUs, sensors, mechanical components, and various systems and subsystems communicate within the vehicle 101. As an example, the vehicle 101 may be a car, bus, truck, lorry, etc., integrated with ECUs and systems that may communicate over the in-vehicle network. In some embodiments, the vehicle 101 may be an autonomous vehicle or a non-autonomous vehicle. In some embodiments, the in-vehicle network may be divided into predefined zones. A predefined zone may be an area within the in-vehicle network that includes, for example, ECUs associated with similar types of functions, ECUs associated with different types of functions, ECUs associated with the same or different levels of criticality, etc. As an example, a "safety system zone" may be a predefined zone that includes safety-related ECUs, such as ECUs for anti-lock braking system (ABS), supplemental restraint system (SRS), and emergency brake assist (EBA). In another example, a "powertrain control zone" may be a predefined zone that includes ECUs associated with engine control, transmission control, and oil supply control. In some embodiments, the primary ECUs 111 and secondary ECUs 113 belonging to each predefined zone 105 of the vehicle 101 may be associated with functions. In some embodiments, the primary ECUs 111 may be critical ECUs that may perform critical functions of the vehicle 101, and the secondary ECUs 113 may be non-critical ECUs that may perform functions of the vehicle 101 that are different from the functions performed by the primary ECUs 111. For example, the primary / critical ECUs 111 may perform critical functions of the vehicle 101, such as safety and security functions, anti-lock braking system (ABS) functions, powertrain functions, surround view and warning functions, gateway functions, etc., and the remaining ECUs, i.e., the secondary / non-critical ECUs 113, may perform functions of the vehicle that are different from the functions of the primary ECUs 111, such as infotainment system functions, heating, ventilation and air conditioning (HVAC) control functions, power window control functions, etc.In some embodiments, each of the multiple primary ECUs 111 and each of the multiple secondary ECUs 113 communicate with each other. In some embodiments, each of the multiple primary ECUs 113 communicate with each other via secure communication, e.g., encrypted communication or authenticated communication.

[0024] In some embodiments, as shown in FIG. 1A, the in-vehicle network includes a predetermined zone 105 1 ~105 n Each predetermined zone 105 of the in-vehicle network may include one zone master ECU 107. Further, each zone master ECU 107 may be communicatively connected to multiple primary ECUs 111 and multiple secondary ECUs 113 within the corresponding predetermined zone 105. For example, as shown in FIG. 1B, the predetermined zone 105 may include: 1 Zone Master ECU 107 1 1B , the predetermined zone 105 may further include a primary ECU 111A, which may be further communicatively connected to a primary ECU 111A and a secondary ECU 113A. The primary ECU 111A may further be communicatively connected to a primary ECU 111A.1 and a primary ECU 111A.2. The secondary ECU 113A may further be communicatively connected to a secondary ECU 113A.1 and a secondary ECU 113A.2. 2 Zone Master ECU 107 2 1A and 1B, which is further communicatively connected to a primary ECU 111B and a secondary ECU 113B. The primary ECU 111B may further be communicatively connected to a primary ECU 111B.1. The secondary ECU 113B may further be communicatively connected to a secondary ECU 113B.1 and a secondary ECU 113B.2. The arrangement of the primary ECUs 111 and the secondary ECUs 113 within the predetermined zone 105 as illustrated in FIGS. 1A and 1B is purely exemplary, and the arrangement may differ or be changed based on the vehicle, the model of the vehicle, the features provided by the vehicle, etc. Thus, the arrangement as illustrated in FIGS. 1A and 1B should not be construed as limiting. This is merely for the reader's understanding.

[0025] Additionally, each zone master ECU 107 may be integrated with an authentication system 109. As shown in FIG. 1A, the zone master ECU 107 1 is an authentication system 109 1 Similarly, the zone master ECU 107 may be integrated with n Authentication System 109 n In some embodiments, the predetermined zone 105 1 ~105 n Zone Master 107 1 ~107 n may be connected to the vehicle master ECU 103 via a communication network (not shown in FIG. 1A). In some embodiments, the communication network may be one of a wired communication network or a wireless communication network.

[0026] Hereinafter, the method of the present disclosure will be described with reference to one authentication system 109, e.g. 1 However, the same method is disclosed for each predetermined zone 105 within the vehicle network. 1 ~105 n Each authentication system 109 that is integrated into 1 ~109 n This should not be construed as a limitation since the authentication system 109 may be implemented by any suitable method. 1 is processor 115 1 and Input / Output (I / O) Interface 117 1 And, Memory 119 1 The processor 115 may include 1 When an authentication request is present in the in-vehicle network, the zone master ECU 105 1The ECU 113A may request pre-assigned, signed unique encryption key shares from each of the multiple primary ECUs 111A associated with the ECU 113A. In some embodiments, the pre-assigned, signed unique encryption key shares exist by performing a process of generating signed unique encryption key shares and assigning the generated signed unique encryption key shares to each of the multiple primary ECUs 111A and secondary ECUs 113A prior to performing the methods disclosed in this disclosure. In some embodiments, the concept and process of generating signed unique encryption key shares and assigning the generated signed unique encryption key shares to various ECUs in an in-vehicle network is disclosed in UK Patent Application No. 2108705.1, entitled "A METHOD AND SYSTEM FOR SECRET KEY SHARING FOR AN IN-VEHICLE NETWORK." The entire disclosure of UK Patent Application No. 2108705.1 is incorporated herein by reference.

[0027] I / O Interface 117 1 Zone Master ECU 107 1 In some embodiments, each of the pre-assigned, signed unique encryption key shares received from the primary ECUs 111A may be encrypted using a random number or nonce. 1 10 uses a predetermined number (K-1) of pre-assigned signed unique cryptographic key shares received from the multiple primary ECUs 111A to perform a predetermined zone 105 1 In some embodiments, a pre-assigned, predetermined number (K-1) of unique signed cryptographic key shares may be calculated at the time of manufacture of the vehicle 101 or at the time of each pre-defined zone 105. 1 ~105 n Zone Master ECU 107 1 ~107 n As an example, the predetermined number (K-1) may be 3, which indicates that the authentication system is installed in the predetermined zone 105. 1This means that the first unique signature for a given zone may be calculated using only the three pre-assigned signed unique encryption key shares received from the multiple primary ECUs 111A. However, this should not be construed as a limitation since the pre-assigned number (K-1) may vary and may be dynamically configurable. In some embodiments, the pre-assigned number (K-1) of unique encryption key shares are selected based on one of a first come, first served (FCFS) technique, a random selection technique, or a rule-based technique. Thereafter, the processor 115 1 uses the public key to verify the validity of the calculated first unique signature to verify the validity of the first unique signature in the predetermined zone 105. 1 In some embodiments, the public key may be a numerical value used for encryption and authentication purposes. In some embodiments, the public key for each given zone 105 is retrieved from a storage unit (not shown in FIGS. 1A and 1B ) associated with the corresponding zone master ECU 107 to verify the validity of the calculated first unique signature. Upon verifying the validity of the calculated first unique signature, the processor 115 1 The verified first unique signature is sent to each predetermined zone 105 1 ~105 n Zone Master ECU 107 1 ~107 n In some embodiments, the vehicle master ECU 103 may provide the vehicle master ECU 103 associated with the predetermined zone 105 using the verified first unique signature, as shown in the example scenario of FIG. 1 and 105 2 However, if there are “n” primary ECUs, the vehicle master ECU 103 may activate the safety functions associated with each of the multiple primary ECUs 111A and 111B. 1 and 105 n The "n" primary ECUs may each be configured to activate a safety function associated with the "n" primary ECUs.

[0028] In some embodiments, the predetermined zone 105 1When performing security verification for the multiple primary ECUs 111A, the processor 115 1 is a given zone 105 1 In some embodiments, the secondary ECUs 113A may be verified after the verification of the primary ECUs 111A in order to prioritize ECUs with critical functions over ECUs with non-critical functions. 1 In order to verify the multiple secondary ECUs 113A, the processor 115 1 Zone Master ECU 107 1 In some embodiments, the processor 115 may request a unique pre-assigned signed cryptographic key share from each of the multiple secondary ECUs 113A associated with the secondary ECU. 1 1 uses a pre-assigned predetermined number (K-1) of unique signed cryptographic key shares received from the multiple secondary ECUs 113A to execute a process for a predetermined zone 105 1 Then, the processor 115 may calculate a second unique signature of 1 uses the public key to verify the validity of the calculated second unique signature to authenticate each of the multiple secondary ECUs in the predetermined zone, and transmits the verified second unique signature to each of the multiple secondary ECUs in the predetermined zone 105. 1 ~105 n Zone Master ECU 107 1 ~107 n In some embodiments, the vehicle master ECU 103 may provide the second unique signature to the vehicle master ECU 103 associated with the predetermined zone 105 using the verified second unique signature, as shown in the example scenario of FIG. 1 and 105 n However, if there are “n” secondary ECUs, the vehicle master ECU 103 may use the verified second unique signature to activate other functions associated with each of the multiple secondary ECUs 113A and 113B. 1 and 105 n The "n" secondary ECUs may each be configured to activate a safety function associated with the "n" secondary ECUs.

[0029] Thus, the method for verifying the security of the vehicle 101 may be an iterative cycle that is executed each time there is an authentication request in the in-vehicle network.

[0030] FIG. 2A illustrates a detailed block diagram of an authentication system 109 for verifying the security of a vehicle, according to some embodiments of the present disclosure.

[0031] In some implementations, an authentication system 109 integrated into each zone master electronic control unit (ECU) 107 may include data 203 and modules 205. As an example, data 203 is stored in memory 119 of authentication system 109 as shown in Figure 2A. In one embodiment, data 203 may include key share data 207, signature data 209, and other data 211. In Figure 2A, modules 205 are described in detail herein.

[0032] In some embodiments, the data 203 may be stored in the memory 119 in the form of various data structures. Additionally, the data 203 may be organized using a data model, such as a relational or hierarchical data model. The other data 215 may store data generated by the module 205 for performing various functions of the authentication system 109, including the public key for a given zone 105, a given number (K-1) of unique cryptographic key shares, temporary data, and temporary files.

[0033] In some embodiments, the key agreement data 207 may include pre-assigned, signed, unique cryptographic key shares received from each of multiple primary ECUs 111 associated with a zone master ECU 107 in a given zone 105. In some embodiments, the authentication system 109 may receive the key agreement data 207 when an authentication request is present in the in-vehicle network.

[0034] In some embodiments, the signature data 209 may include a first unique signature of the given zone 105 and a second unique signature of the given zone 105. In some embodiments, the first unique signature of the given zone 105 may be associated with multiple primary ECUs 111 present in the given zone 105, and the second unique signature of the given zone 105 may be associated with multiple secondary ECUs 113 present in the given zone 105. The first unique signature may be determined using a predetermined number (K-1) of pre-assigned signed unique cryptographic key shares received from the multiple primary ECUs 111. Similarly, the second unique signature may be determined using a predetermined number (K-1) of pre-assigned signed unique cryptographic key shares received from the multiple secondary ECUs 113. In some embodiments, the first unique signature and the second unique signature may be calculated each time the key share data 207 is received from the multiple primary ECUs 111 and secondary ECUs 113. In other words, the first unique signature and the second unique signature may be calculated each time there is an authentication request during the start-up phase or any other phase of the vehicle 101.

[0035] In some embodiments, the data 203 stored in the memory 119 may be processed by a module 205 of the authentication system 109. The module 205 may be stored within the memory 119. In one example, the module 205 communicatively coupled to the processor 115 of the authentication system 109 may reside outside the memory 119 and be implemented as hardware, as shown in FIG. 2A. As used herein, the term module 205 may refer to an application specific integrated circuit (ASIC), electronic circuitry, processors (shared, dedicated or group) executing one or more software or firmware programs and memory, combinatorial logic circuitry, and / or other suitable components that provide the described functionality.

[0036] In some embodiments, the modules 205 may include, for example, a signature calculation module 221, a receiving module 223, a signature verification module 225, a sending module 227, and other modules 229. The other modules 229 may be used to perform various miscellaneous functions of the authentication system 109. It will be appreciated that such aforementioned modules 205 may be represented as a single module or a combination of different modules.

[0037] In some embodiments, the signature calculation module 221 may request a pre-assigned unique signed cryptographic key share from each of the primary ECUs 111 associated with the zone master ECU 107 when an authentication request is present in the in-vehicle network. 1 Zone Master ECU 107 1 Authentication system 109 1 Therefore, the signature calculation module 221 considers that the signature exists in the zone master ECU 107. 1 In some other embodiments, the signature calculation module 221 may request a pre-assigned unique cryptographic key share from each of the multiple primary ECUs 111A associated with the zone master ECU 107. 1The authentication request may request pre-assigned signed unique cryptographic key shares from some of the primary ECUs 111A associated with the vehicle 101. However, some of the primary ECUs 111A must have more than a pre-defined number (K-1) of pre-assigned signed unique cryptographic key shares required to calculate the first unique signature. In some embodiments, the authentication request may be any notification indicating a requirement to authenticate the primary ECUs 111 and / or the secondary ECUs 113 integrated into each pre-defined zone 105 of the in-vehicle network. In some embodiments, the authentication request may occur at a start-up phase of the vehicle 101. In some other embodiments, the authentication request may occur after the start-up of the vehicle 101, in other words, the authentication request may occur when there is at least one occurrence of a pre-defined event. As an example, the pre-defined event may be an ignition on / off state, a wake-up mode of the ECU, a sleep mode of the ECU, a bus recovery state, receiving a pre-defined type of message or data, and transmitting a pre-defined type of message or data, etc.

[0038] The receiving module 223 may then receive the pre-assigned signed unique encryption key shares received from the multiple primary ECUs 111A. In some embodiments, the concept and process of generating the signed unique encryption key shares and assigning the generated signed unique encryption key shares to various ECUs in an in-vehicle network prior to performing the methods disclosed in this disclosure is disclosed in UK Patent Application No. 2108705.1, entitled "A METHOD AND SYSTEM FOR SECRET KEY SHARING FOR AN IN-VEHICLE NETWORK." The entire disclosure of UK Patent Application No. 2108705.1 is incorporated herein by reference. In some embodiments, the pre-assigned signed unique encryption key shares thus received from the multiple primary ECUs 111A may be encrypted using a random number or nonce. In some other embodiments, the pre-assigned signed unique encryption key shares thus received from the multiple primary ECUs 111A may be in plain text format. In some embodiments, each unique encryption key share may be signed prior to assignment. For example, a unique cryptographic key share may be signed using Equation 1 below: Sig(ECU i )=m yi mod N - Equation 1 In the above formula 1, "i" may refer to an integer (1, 2...n), "m" may refer to a preconfigured value, "y" may refer to a unique encryption key share, so y 1 , y 2 , ..., y k Zone Master ECU 107 1 are the unique encryption key shares of the original encryption key of "N" may refer to a public key, "Mod N" may refer to the modulo of the public key determined using a predetermined modular arithmetic technique.

[0039] In some embodiments, the signature calculation module 221 may then calculate a first unique signature for the given zone using the pre-assigned predetermined number (K-1) of unique cryptographic key shares received from the multiple primary ECUs. As an example, the predetermined number (K-1) may be 3, which indicates that the authentication system is configured to 1 This means that the first unique signature of a given zone may be calculated using only three pre-assigned signed unique encryption key shares received from the multiple primary ECUs 111A. However, this should not be construed as limiting, as the pre-assigned number (K-1) may vary and be dynamically configurable. In some embodiments, the pre-assigned number (K-1) of unique encryption key shares are selected based on one of a first-come, first-served (FCFS) technique, a random selection technique, or a rule-based technique. As an example, the signature calculation module 221 may calculate the first unique signature using the first three pre-assigned signed unique encryption key shares received from the three primary ECUs. In another example, the signature calculation module 221 may randomly select the three pre-assigned signed unique encryption key shares received from the three primary ECUs to calculate the first unique signature. In yet another example, the signature calculation module 221 may select the three unique encryption key shares received from the three different ECUs based on one or more pre-assigned rules to calculate the first unique signature. As an example, if a predefined rule indicates "select the signed unique cryptographic key shares received from the primary ECU associated with the anti-lock braking function to calculate the first unique signature," the signature calculation module 221 may select three unique cryptographic key shares received from three primary ECUs associated with the anti-lock braking system (ABS) function and use them to calculate the first unique signature.

[0040] In some embodiments, the signature calculation module 221 calculates the value of the signature for the given zone 105 using the following Equation 2: 1 The primary ECU 111A may calculate a first unique signature based on the pre-assigned signed unique cryptographic key shares received from the multiple primary ECUs 111A. Sig(ECU 1 +ECU 2 +,...,+ECU k-1 )=m S mod N - Equation 2 In the above formula 2, Sig(ECU 1 +ECU 2 +,...,+ECU k-1 ) denotes an aggregation of signed unique cryptographic key shares received from multiple primary ECUs; "m" is a preconfigured value, "S" is equal to (y1+y2,...,+yk-1), where "y" is the unique encryption key share; "K-1" denotes a predetermined number of unique signed cryptographic key shares required to compute a unique first signature, "N" is the public key, "mod N" is the modulo of the public key determined using a predetermined modular arithmetic technique.

[0041] In the above Equation 2, the signature calculation module 221 may aggregate the (K-1) number of signed unique encryption key shares received from the multiple primary ECUs 111A to obtain a unique first signature. In some embodiments, the (K-1) number of signed unique encryption key shares may be aggregated in the following form: As shown in Equation 2, m S mod N. Let "S" denote the sum of the (K-1) number of signed unique encryption key shares, i.e., (y1+y2,...,+yk-1). As an example, consider the predetermined number (K-1) to be 3. Thus, the first unique signature may be calculated using Equation 2 as shown below: Sig(ECU 1 +ECU 2 +ECU 3 ), i.e. [unique first signature] = m (y1+y2+y3) mod N

[0042] In some embodiments, a public key "N" for each given zone 105 is retrieved from a storage unit associated with the corresponding zone master ECU 107 of the corresponding given zone 105 to verify the validity of the calculated first unique signature. In some embodiments, the public key "N" may be different for each given zone 105. The public key "N" may be one of the predefined ones or may be dynamically configured when there is an authentication request.

[0043] In some embodiments, upon calculating the first unique signature, the signature verification module 225 verifies the validity of the calculated first unique signature to verify the validity of the first unique signature in the predetermined zone 105. 1 In some embodiments, the validity of the calculated first signature may be determined based on the validity of the first signature within the predetermined zone 105. 1 The first unique signature may be verified using the public key (N, e) of the pre-assigned unique signed cryptographic key share. In some embodiments, verifying the validity of the computed first unique signature may include checking whether a first unique signature formed using the (K-1) shares of the pre-assigned unique signed cryptographic key share corresponds to the original cryptographic key. In some embodiments, each combination of the (K-1) shares of the pre-assigned unique signed cryptographic key share may result in a different first unique signature. However, the first unique signature so formed may not be unique to the pre-assigned zone 105. 1 The original encryption key should be followed.

[0044] In some embodiments, the first unique signature is 1 If the verification is successful, the transmission module 227 transmits the verified unique first signature to each of the predetermined zones 105. 1 ~105 n Zone Master ECU 107 1 ~107 n Similarly, the zone master ECU 107 may provide the vehicle master ECU 103 associated with the zone master ECU 107. 1 ~107 nEach transmission module 227 of the zone master ECU 107 may transmit a corresponding verified first unique signature to the vehicle master ECU 103. 1 ~107 n Upon receiving a corresponding verified first unique signature from each of the zone master ECUs 107, the vehicle master ECU 103 may verify the security of the vehicle 101 as a whole. In some embodiments, to verify the security of the vehicle 101 as a whole, the vehicle master ECU 103 may 1 ~107 n In some embodiments, the first unique signature received from each of the predetermined zones 105 may be successfully verified. 1 The successful verification of the validity of the first unique signature of the predetermined zone 105 1 Therefore, the authenticity of the primary ECUs 111A present in the predetermined zone 105 can be indicated. 1 ~105 n If each of the first unique signatures is identified as valid, the vehicle master ECU 103 1 ~105 n The vehicle master ECU 103 may identify each of the multiple primary ECUs 111 present in each of the predetermined zones 105 as valid, thereby verifying the security of the vehicle 101, or more precisely, the critical security of the vehicle 101, since only the multiple primary ECUs 111 were initially authenticated. 1 ~105 n The first unique signature may activate one or more safety features associated with each of the multiple primary ECUs 111 of the vehicle. In some embodiments, the safety features may be equivalent to critical features associated with the vehicle. By way of example, the safety / critical features may include, but are not limited to, airbag features, anti-lock braking system (ABS) features, powertrain features, surround view and warning features, gateway features, and the like. 1 ~105 nIf the first unique signature is determined to be invalid for any of the plurality of primary ECUs 111, the vehicle master ECU 103 may determine that one or more of the plurality of primary ECUs 111 has been attacked by a third party attacker / hacker. 1 ~105 n If any of the zone master ECUs 107 are identified as not being valid for any of the zones, the corresponding zone master ECU 107 may itself notify the vehicle master ECU 103 of such security violation, enabling the vehicle master ECU 103 to take appropriate action regarding such security violation.

[0045] In some embodiments, the predetermined zone 105 1 ~105 n When verifying the security of the vehicle 101 against the multiple primary ECUs 111 in each of the zone master ECUs 107, the authentication system 109 may verify the security of the vehicle 101 against the multiple secondary ECUs 113. In some embodiments, the authentication system 109 may verify the security of the vehicle 101 against the multiple secondary ECUs 113 using the same methods as disclosed above for verifying the security of the vehicle 101. However, to briefly reiterate, the signature calculation module 221 may verify the security of the vehicle 101 against the multiple secondary ECUs 113 using the same methods as disclosed above for verifying the security of the vehicle 101. 1 The signature calculation module 221 may then request pre-assigned, signed unique encryption key shares from each of the multiple secondary ECUs 113A associated with the predetermined zone 105. The reception module 223 may then receive the pre-assigned, signed unique encryption key shares received from the multiple secondary ECUs 113A. The signature calculation module 221 may then calculate the pre-assigned, signed unique encryption key shares for the predetermined zone 105 using the predetermined number (K-1) of pre-assigned, signed unique encryption key shares received from the multiple secondary ECUs 113A. 1In some embodiments, the signature calculation module 221 may calculate the second unique signature using Equation 2, which is the same equation used to calculate the first unique signature. Upon calculating the second unique signature, the signature verification module 225 uses the public key (N, e) to verify the validity of the calculated second unique signature to verify the validity of the second unique signature for the given zone 105. 1 The transmission module 227 may then transmit the verified second unique signature to the predetermined zone 105. 1 Zone Master ECU 107 1 The vehicle master ECU 103 associated with the vehicle may provide the vehicle master ECU 103 with the vehicle master ECU 103 associated with the vehicle master ECU 103 .

[0046] In some embodiments, the vehicle master ECU 103 may perform security verification based on the first unique signature by using the predetermined zone 105 as described above in this disclosure. 1 ~105 n Each zone master ECU107 1 ~107 n 10 to verify the security of the vehicle as a whole. In some embodiments, upon verifying the security of the vehicle 101 based on the second unique signature, the vehicle master ECU 103 may activate other functions associated with each of the plurality of secondary ECUs 113. In some embodiments, the other functions may be equivalent to non-critical functions of the vehicle 101. By way of example, the other / non-critical functions of the vehicle 101 may include, but are not limited to, infotainment system functions, heating, ventilation, and air conditioning (HVAC) control functions, power window control functions, etc.

[0047] In the following, a process for verifying the security of a vehicle is described by one or more examples for a better understanding of the present disclosure, but the one or more examples should not be considered as limitations of the present disclosure.

[0048] Consider an example diagram as shown in Figure 2B. In this scenario, consider an in-vehicle network deployment as shown in Table 1 below.

[0049] [Table 1]

[0050] When the vehicle start-up phase occurs, authentication of the ECUs of the vehicle 101 is required. The faster the authentication / verification of the security of the vehicle 101, the better the user experience. Therefore, to ensure a fast start-up, the present disclosure discloses a method to first verify the most important primary ECUs (critical ECUs) 111 in each predefined zone 105, followed by verification of the secondary ECUs (non-critical ECUs) 113. In this exemplary scenario, if there is an authentication request, the following actions occur in parallel in PZ-1 and PZ-2 for the primary ECUs, as shown in Table 2:

[0051] [Table 2]

[0052] The VME 103 receives FUS-1 and FUS-2 from ZME-1 in PZ-1 and ZME-2 in PZ-2, respectively, and verifies the security of the vehicle 101 based on the authenticity and validity of the primary / critical ECU 111. If the critical ECU is attacked by a third party attacker, it may completely compromise the security of the vehicle 101 and hand over the control of the vehicle 101 to the third party attacker. Therefore, authenticating the critical ECU first not only allows checking the authenticity of the most critical ECU of the vehicle 101 with full coverage, but also ensures high security. Moreover, the method disclosed in the present disclosure is not a sequential method of authenticating each ECU of a given zone one after another, rather, the method disclosed in the present disclosure allows parallel verification with only a predetermined number (K-1) of key shares received in each of the given zones and from the primary ECUs in each zone. Thus, the present disclosure eliminates the need to wait for a response from each ECU to authenticate that ECU. Rather, the present disclosure enables the use of (K-1) key shares received from (K-1) number of primary ECUs in a given zone, and authenticates each of the primary ECUs in that zone at once based on a unique signature calculated using the (K-1) key shares. Upon verifying the security of the vehicle 101 based on FUS-1 and FUS-2, the VME 103 activates secure / critical functions such as ABS functions, airbag functions, powertrain functions, etc.

[0053] ZME-1 and ZME-2 then perform the same method for each of the multiple secondary ECUs 113 in the given zones PZ-1 and PZ-2. In this example scenario, if there is an authentication request, in parallel, the following actions occur in PZ-1 and PZ-2 for the secondary ECUs, as shown in Table 3:

[0054] [Table 3]

[0055] The VME 103 receives SUS-1 and SUS-2 from ZME-1 of PZ-1 and ZME-2 of PZ-2, respectively, and verifies the security of the vehicle 101 based on the authenticity and validity of the secondary / non-critical ECUs 111. Since the secondary ECUs are non-critical in nature, validating the secondary ECUs even after the start-up phase after the validation of the primary ECUs (required for the start-up itself) may not harm the in-vehicle network. Moreover, performing the validation of the secondary / non-critical ECUs at a later stage after start-up may improve the speed of validation of the primary / critical ECUs in the start-up phase, eliminating unnecessary delays during the start-up phase, improving the coverage of the primary / critical ECUs in the start-up phase, and also improving the user experience due to faster validation of critical security health checks leading to faster start-up. Upon validating the security of the vehicle 101 based on SUS-1 and SUS-2, the VME 103 activates secure / critical functions such as infotainment system functions, heating, ventilation and air conditioning (HVAC) control functions, power window control functions, etc.

[0056] FIG. 3 shows a flow chart illustrating a method for verifying the security of a vehicle according to some embodiments of the present disclosure.

[0057] 3, the method 300 includes one or more blocks illustrating a method for verifying security of the vehicle 101. The method 300 may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions that perform functions or implement abstract data types.

[0058] The order in which method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined in any order to implement method 300. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Further, method 300 may be implemented in any suitable hardware, software, firmware, or combination thereof.

[0059] At block 301, the method 300 includes: 1 One of the zone master electronic control units (ECU) 107 1 Authentication system 109 to be integrated into 1 The processor 115 of the zone master ECU 107 1 The process may include requesting a pre-assigned, signed unique encryption key share from each of the multiple primary ECUs 111A associated with the primary ECU 111A. In some embodiments, the processor 115 may request a pre-assigned, signed unique encryption key share from each of the multiple primary ECUs 111A when an authentication request is present in the in-vehicle network. In some embodiments, the pre-assigned, signed unique encryption key share received from the multiple primary ECUs 111A is encrypted using a random number or nonce.

[0060] At block 303, the method 300 may include computing, by the processor 115, a first unique signature for the given zone using the predetermined number (K-1) of pre-assigned signed unique encryption key shares received from the multiple primary ECUs 111A. In some embodiments, the predetermined number (K-1) may be a minimum number of pre-assigned signed unique encryption key shares required to compute the first unique signature and the second unique signature. In some embodiments, the predetermined number (K-1) of unique encryption key shares are selected based on one of a first come, first served (FCFS) technique, a random selection technique, or a rule-based technique.

[0061] At block 305, the method 300 includes verifying, by the processor 115, the validity of the calculated first unique signature using the public key to verify the validity of the first unique signature in the given zone 105. 1 In some embodiments, the public key for each given zone may include authenticating each of the multiple primary ECUs 111A in the zone master ECU 107 to verify the validity of the calculated first and second unique signatures. 1 The information may be obtained from a storage unit associated with the

[0062] At block 307, the method 300 includes, by the processor 115, transmitting the verified first unique signature to each of the predetermined zones 105. 1 ~105 n Zone Master ECU 107 1 ~107 n The vehicle master ECU 103 then provides the vehicle master ECU 103 with the predetermined zone 105 1 ~105 n The method may include enabling activation of a safety function associated with each of the multiple primary ECUs 111.

[0063] In some embodiments, the processor 115 may be configured to determine whether the vehicle master ECU 103 is configured to recognize the vehicle 101 in the predetermined zone 105 after the vehicle master ECU 103 verifies the security of the vehicle 101 based on the plurality of primary ECUs 111. 1 Zone Master ECU 107 1 In some embodiments, while performing the steps of blocks 301 to 307 for the multiple secondary ECUs 113A associated with each of the predetermined zones 105, a second unique signature may be calculated for verification. 1 ~105 n Each zone master ECU107 1 ~107 n may be provided to the vehicle master ECU 103 to verify the security of the vehicle 101 based on the multiple secondary ECUs 113 associated with them.

[0064] FIG. 4 is a block diagram of an exemplary computer system for implementing embodiments consistent with this disclosure.

[0065] In some embodiments, Figure 4 illustrates a block diagram of an exemplary computer system 400 for implementing an embodiment consistent with the present invention. In some embodiments, the computer system 400 may be an authentication system 109 associated with a zone master electronic control unit (ECU) 107 for verifying the security of the vehicle 101, as shown in Figure 4. In some other embodiments, the computer system 400 may be associated with a zone master ECU 107 for verifying the security of the vehicle 101. 1 ~107 n The vehicle master ECU 103 may be associated with each of the vehicle ECUs 102 and 103a and 103b. The computer system 400 may include a central processing unit ("CPU" or "processor") 402. The processor 402 may include at least one data processor for executing program components for executing user or system generated business processes. A user may include a person, a person using a device such as those included in the present invention, or such a device itself. The processor 402 may include dedicated processing units such as an integrated system (bus) controller, a memory management control unit, a floating point unit, a graphics processing unit, a digital signal processing unit, etc.

[0066] The processor 402 may be arranged to communicate with input devices 411 and output devices 412 via an I / O interface 401. The I / O interface 401 may employ communications protocols / methods including, but not limited to, audio, analog, digital, stereo, IEEE-1394, serial bus, universal serial bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital visual interface (DVI), high definition multimedia interface (HDMI), radio frequency (RF) antenna, S-Video, video graphics array (VGA), IEEE 802.n / b / g / n / x, Bluetooth, cellular (e.g., code division multiple access (CDMA), high speed packet access (HSPA+), Global System for Mobile Communications (GSM), long term evolution (LTE), WiMax, etc.).

[0067] Using the I / O interface 401 , the computer system 400 can communicate with input devices 411 and output devices 412 .

[0068] In some embodiments, the processor 402 may be arranged to communicate with a communications network 409 via a network interface connection 403. The network interface 403 may communicate with the communications network 409. The network interface 403 may employ a connection protocol including, but not limited to, direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000BaseT), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc. Using the network interface 403 and the communications network 409, the computer system 400 may communicate with multiple zone master ECUs 107 (107 1 ~107 n) which can then communicate with the vehicle master ECU 103 as well as multiple primary ECUs 111 (111) via internet or non-internet or non-IP based communications such as Universal Serial Bus (USB), Bluetooth, etc. 1 ~111 n ) and multiple secondary ECUs 113 (113 1 ~113 n 4 ). The communication network 409 can be implemented as one of different types of networks, such as an intranet or local area network (LAN), a closed area network (CAN), etc., and within an autonomous vehicle. The communication network 409 can be either a dedicated network or a shared network, which represents an association of different types of networks that use various protocols, such as HyperText Transfer Protocol (HTTP), CAN protocol, Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Furthermore, the communication network 409 can include various network devices, including routers, bridges, servers, computing devices, storage devices, etc. In some embodiments, the processor 402 can be arranged to communicate with a memory 405 (e.g., RAM, ROM, etc., not shown in FIG. 4 ) via a storage interface 404. The storage interface 404 may be connected to memory 405 including, but not limited to, memory drives, removable disk drives, etc., employing a connection protocol such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer System Interface (SCSI), etc. The memory drives may further include drum, magnetic disk drives, magneto-optical drives, optical drives, Redundant Array of Independent Disks (RAID), solid state memory devices, solid state drives, etc.

[0069] Memory 405 may store a collection of program or database components, including but not limited to a user interface 406, an operating system 407, a web browser 408, etc. In some embodiments, computer system 400 may store user / application data, such as data, variables, records, etc., as described herein. Such databases may be implemented as fault-tolerant, relational, scalable, and secure databases, such as Oracle or Sybase.

[0070] Operating system 407 may facilitate resource management and operation of computer system 400. Examples of operating systems 407 include, but are not limited to, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (e.g., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® distributions (e.g., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS / 2®, MICROSOFT® WINDOWS® (XP®, VISTA® / 7 / 8, 10, etc.), APPLE® IOS®, GOOGLE® ANDROID®, BLACKBERRY® OS, etc. The user interface 406 may facilitate the display, execution, interaction, manipulation, or operation of program components through textual or graphical features. For example, the user interface 406 may provide computer interaction interface elements, such as cursors, icons, checkboxes, menus, scrollers, windows, widgets, etc., on a display system operatively connected to the computer system 400. Graphical user interfaces (GUIs) may be employed, including, but not limited to, Apple® Macintosh® operating systems Aqua®, IBM® OS / 2®, Microsoft® Windows® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, Java®, Javascript®, AJAX, HTML, Adobe® Flash®, etc.), and the like.

[0071] In some embodiments, computer system 400 may implement a web browser 408 stored program component. Web browser 408 may be a hypertext browsing application such as MICROSOFT® INTERNET EXPLORER®, GOOGLE™ CHROME™, MOZILLA® FIREFOX®, APPLE® SAFARI®, etc. Secure web browsing may be provided using Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browser 408 may utilize functionality such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, application programming interfaces (APIs), etc. In some embodiments, computer system 400 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange. The mail server may utilize functions such as Active Server Pages (ASP), ACTIVEX, ANSI C++ / C#, MICROSOFT.NET, CGI script, JAVA, JAVASCRIPT, PERL, PHP, PYTHON, WEBOBJECTS, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), etc. In some embodiments, computer system 400 may implement a mail client stored program component.The mail client may be a mail viewing application such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, or the like.

[0072] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory in which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard drives, compact disc (CD) ROM, digital video disc (DVD), flash drive, disk, and any other known physical storage medium.

[0073] Overall, the present disclosure provides a viable security verification for critical ECUs in a vehicle during the start-up phase. The present disclosure ensures the authenticity of the critical ECUs and prevents them from being compromised by an attacker. Thus, the present disclosure: Achieving faster checks of authentication and start-up by using a single-step security verification for a group of ECUs instead of multiple security verifications for each ECU. - Reduce security verification timing and improve user experience levels. - Ensuring the certification of critical ECUs during the start-up phase, within balanced performance and cost factors.

[0074] A description of an embodiment having several components in communication with each other does not imply that all such components are required. On the contrary, various optional components are described to illustrate the wide variety of possible embodiments of the present invention. Where a single device or article is described herein, it will be apparent that more than one device / article (whether they cooperate or not) may be used in place of the single device / article. Similarly, where more than one device or article is described herein (whether they cooperate or not), it will be apparent that a single device / article may be used in place of more than one device or article, or a different number of devices / articles may be used in place of the number of devices or programs illustrated. The functionality and / or features of a device may alternatively be embodied by one or more other devices not explicitly described as having such functionality / features. Thus, other embodiments of the present invention need not include a device per se.

[0075] This specification has described a method and system for verifying vehicle security. The illustrated steps are presented to explain the illustrated exemplary embodiment, and it is to be expected that ongoing technological developments will change the manner in which certain functions are performed. These examples are presented herein for illustrative purposes and are not limiting. Furthermore, the boundaries of functional building blocks have been arbitrarily defined herein for convenience of description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc. of those described herein) will be apparent to those skilled in the relevant art based on the teachings contained herein. Such alternatives are within the scope and spirit of the disclosed embodiments. Additionally, the words "comprise," "have," "contain," and "include," as well as other similar forms, are intended to be equivalent in meaning and open-ended in that the item or items following any one of these words are not meant to be an exhaustive listing of such items or items, or to be limited only to the listed item or items. Please also note that as used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0076] Finally, the language used herein has been selected primarily for ease of reading and teaching purposes, and not to delineate or limit the subject matter of the present invention. Accordingly, it is intended that the scope of the invention be limited not by this detailed description, but by any claims that issue on an application based hereon. Accordingly, the embodiments of the present invention are intended to illustrate, but not limit, the scope of the invention, which is set forth in the following claims. [Explanation of symbols]

[0077] 100 Architecture 101 vehicles 103 Vehicle Master ECU 105 designated zone 107 Zone Master ECU 109 Authentication System 111 Multiple Primary ECUs 113 Multiple Secondary ECUs 115 Processors 117 I / O Interface 119 Memory 203 Data 205 Module 207 Key sharing data 209 Signature Data 211 Other Data 221 Signature Calculation Module 223 Receiver Module 225 Signature Verification Module 227 Transmitting Module 229 Other Modules 400 Exemplary Computer System 401 I / O Interfaces of an Exemplary Computer System 402 Processor of an Exemplary Computer System 403 Network Interface 404 Storage Interface 405 Memory of an Exemplary Computer System 406 User Interface 407 Operating System 408 Web Browser 409 Communication Network 411 Input Devices 412 Output Device

Claims

1. A method for verifying security of a vehicle, the method comprising: an in-vehicle network of the vehicle (101) comprising a vehicle master ECU (103) and divided into predetermined zones (105), each of the predetermined zones (105) comprising a plurality of ECUs classified as at least one of a primary ECU (111) or a secondary ECU (113); each predetermined zone (105) further comprising a zone master ECU (107) associated with each of the plurality of ECUs of the corresponding predetermined zone; the method comprising: Predetermined zone (105 １ a zone master ECU (107) including an authentication system (109) for requesting, when an authentication request is present in an in-vehicle network, a signed unique encryption key share that is pre-assigned to the primary ECU (111) from a plurality of primary ECUs (111) associated with the zone master ECU (107); calculating, by the authentication system (109), a first unique signature for the predetermined zone using a predetermined number (K-1) of the pre-assigned signed unique cryptographic key shares received from the plurality of primary ECUs (111); The authentication system (109) verifies the validity of the calculated first unique signature using a public key to authenticate the predetermined zone (105). １ authenticating each of the plurality of primary ECUs (111) in the providing the verified first unique signature by the authentication system (109) to the vehicle master ECU (103) associated with the zone master ECU (107) of each predetermined zone (105) to enable the vehicle master ECU (103) to activate a safety function associated with each of the plurality of primary ECUs (111) of each predetermined zone (105); A method comprising:

2. requesting, by the authentication system (109), a unique cryptographic key share with a signature assigned to each of a plurality of secondary ECUs (113) associated with the zone master ECU (107) when verifying the plurality of primary ECUs (111); The authentication system (109) authenticates the predetermined zone (105) using the predetermined number (K-1) of the pre-assigned signed unique encryption key shares received from the plurality of secondary ECUs (113). １ ) and The authentication system (109) uses the public key to verify the validity of the calculated second unique signature to authenticate the predetermined zone (105). １ authenticating each of the plurality of secondary ECUs (113) in the providing the verified second unique signature to the vehicle master ECU (103) associated with the zone master ECU (107) of each predetermined zone (105) by the authentication system (109) to enable the vehicle master ECU (103) to activate other functions associated with each of the plurality of secondary ECUs (113) of each predetermined zone (105); The method of claim 1 further comprising:

3. 2. The method of claim 1, wherein the predetermined number (K-1) of the unique encryption key shares are selected based on one of a first come, first served (FCFS) technique, a random selection technique, or a rule-based technique.

4. 2. The method of claim 1, further comprising retrieving, by the authentication system (109), the public key for each given zone from a storage unit associated with the corresponding zone master ECU (107) to verify the validity of the calculated first and second unique signatures.

5. The method of claim 1, comprising encrypting, by the authentication system (109), the pre-assigned signed unique cryptographic key shares received from the multiple primary ECUs (111) using a random number.

6. The authentication system (109) Sign (EECU) ｉ )=m ｙｉ mod N 2. The method of claim 1, further comprising: signing each of the pre-assigned unique encryption key shares using a unique encryption key share (i, m, y) where "i" is an integer (1, 2...n), "m" is a pre-configured value, "y" is the unique encryption key share, "N" is the public key, and mod N is a modulo of the public key determined using a predetermined modular arithmetic technique.

7. The authentication system (109) Sign (EECU) １ ++ECU ２ +,...,+ECU ｋ－１ )=m Ｓ mod N calculating the unique first signature and the unique second signature using the formula: Sig(ECU １ + ECU ２ +,. .. .. ,+ECU ｋ－１ 2. The method of claim 1, wherein "m" denotes a signed unique encryption key share received from at least one of the plurality of primary ECUs (111) or the plurality of secondary ECUs (113), "S" is equal to (y1+y2,...,+yk-1), where "y" is the unique encryption key share, "K-1" denotes a predetermined number of unique encryption key shares required to compute the unique first signature or the unique second signature, "N" is the public key, and mod N is a modulo of the public key determined using a predetermined modular arithmetic technique.

8. An authentication system (109) for verifying security of a vehicle (101), wherein an in-vehicle network of the vehicle (101) includes the vehicle master ECU (103) and is divided into predetermined zones (105), each of the predetermined zones (105) includes a plurality of ECUs classified as at least one of a primary ECU (111) or a secondary ECU (113), and each predetermined zone (105) further includes a zone master ECU (107) associated with each of the plurality of ECUs of the corresponding predetermined zone, and the authentication system (109) includes: A processor (115); A memory (119) communicatively coupled to the processor (115), storing processor instructions that, when executed, cause the processor (119) to: When an authentication request is present in the in-vehicle network, requesting from a plurality of primary ECUs (111) associated with the zone master ECU (107) a signed unique cryptographic key share pre-assigned to the primary ECU (111); The predetermined zone (105) is encrypted using the pre-assigned unique cryptographic key shares (K-1) received from the plurality of primary ECUs (111). １ ) and 105. Using a public key, verify the validity of the calculated first unique signature to verify the validity of the first unique signature for the predetermined zone (105). １ authenticating each of the plurality of primary ECUs (111) in the providing the verified first unique signature to the vehicle master ECU (103) associated with the zone master ECU (107) of each predetermined zone (105) to enable the vehicle master ECU (103) to activate a safety function associated with each of the plurality of primary ECUs (111) of each predetermined zone (105); A memory (119) for performing the above. An authentication system (109).

9. The processor (115) requesting, upon verification of the plurality of primary ECUs (111), from each of a plurality of secondary ECUs (113) associated with the zone master ECU (107) a signed unique cryptographic key share that has been pre-assigned to the secondary ECU (113); The predetermined zone (105) is encrypted using the pre-assigned unique cryptographic key shares (K-1) received from the plurality of secondary ECUs (113). １ ) and 105. Using the public key, verify the validity of the calculated second unique signature to verify the validity of the second unique signature for the predetermined zone ( １ authenticating each of the plurality of secondary ECUs (113) in the providing the verified second unique signature to the vehicle master ECU (103) associated with the zone master ECU (107) for each predetermined zone (105) to enable the vehicle master ECU (103) to activate other functions associated with each of the plurality of secondary ECUs (113) for each predetermined zone (105); The authentication system (109) of claim 8, further configured to:

10. 10. The authentication system of claim 8, wherein the processor selects the predetermined number (K-1) of unique cryptographic key shares based on one of a first-come, first-served (FCFS) technique, a random selection technique, or a rule-based technique.

11. 9. The authentication system of claim 8, wherein the processor retrieves the public key for each given zone from a storage unit associated with the corresponding zone master ECU to verify the validity of the calculated first and second unique signatures.

12. The authentication system (109) of claim 8, wherein the processor (115) encrypts the pre-assigned signed unique cryptographic key shares received from the multiple primary ECUs (111) using random numbers.

13. The processor (115) is Sign (EECU) ｉ )=m ｙｉ mod N 9. The authentication system (109) of claim 8, wherein "i" is an integer (1, 2...n), "m" is a preconfigured value, "y" is the unique encryption key share, "N" is a public key, and mod N is a modulo of the public key determined using a predetermined modular arithmetic technique.

14. The processor (115) is Sign (EECU) １ ++ECU ２ +,...,+ECU ｋ－１ )=m Ｓ mod N Calculate the unique first signature and the unique second signature using the formula: Sig(ECU １ + ECU ２ +,. .. .. ,+ECU ｋ－１ 9. The authentication system (109) of claim 8, wherein "m" denotes a signed unique encryption key share received from at least one of the plurality of primary ECUs (111) or the plurality of secondary ECUs (113), "S" is equal to (y1+y2,...,+yk-1), where "y" is the unique encryption key share, "K-1" denotes a predetermined number of unique encryption key shares required to compute the unique first signature or the unique second signature, "N" is a public key, and mod N is a modulo of the public key determined using a predetermined modular arithmetic technique.

Images