FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
The patent Rule, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR PERFORMING KEY ENCRYPTION AND CYBER
SECURITY IN VEHICLES USING SSM”
MINDA CORPORATION LIMITED of E-5/2, Chakan Industrial Area, Phase- III M.I.D.C. Nanekarwadi, Tal: Khed, Dist., Pune, Maharashtra, 410-501, India
The following specification particularly describes the invention and the mannerin which it is to be performed

FIELD OF THE DISCLOSURE
The present disclosure relates generally to method and system for performing a key encryption and cyber security within the vehicles. In particular, it relates to provisioning key encryption and cyber security in vehicles using SSM (Software Security Module).
BACKGROUND
It is very critical to provide cyber security to the modern vehicles for inter and intra vehicle communications. Vehicle security research or cyber security for vehicles is getting more and more traction and prominence, because of the inherent dangers of an attacker gaining unauthorized control of the vehicle. The cyber attack is prevalent by way of getting malicious code executed on the vehicle by varied ways including the secondary storage, Bluetooth stack and the telematics unit. The intruders can inject messages into the CAN bus of the vehicle and affect the normal functioning of the vehicle by gaining the physical access to the vehicle, e.g. steering could be controlled via externally injected CAN messages. Intruders administer variety of functions which includes but not limited to controlling the display on the speedometer, killing the engine, controlling the steering, exercise a control on braking systems etc. to name a few.
Since, ECUs (Electronic Control Units) are the building blocks of vehicle platforms, any security proposal that would not consider realistic assumptions of securing ECUs is incomplete and thus inefficient. Modern automotive architectures are complex and often comprise of hundreds of ECUs. The increasing deployment of ECUs complemented with the impending availability of several communication technologies in vehicles has considerably altered the means of transportation by provisioning various services that provide entertainment, enhanced safety, infotainment, telematics, diagnostics, advanced driving assistance and many others with the external world. At the same time, this rapid evolution has fetched various security and privacy challenges to the automotive domain as connected vehicles have become attractive targets to a wide spectrum of cyber attacks that can be serious enough to threaten people’s lives. Thus, the current automotive

standards along with the complex automotive architectures, complicate the task of adding security to all ECUs. For example, the intruder can send the messages to all ECUs that control physical attributes of the vehicle. Most vehicles have the ability to sync a device over Bluetooth. This represents a remote signal of some complexity processed by an ECU. This allows the intruder to access the address book of the phone, make phone calls, stream music and perform other functionality. Due to the dominant security issues at every layer of vehicle architecture, a significant attention has been paid to secure both inter-vehicle and intra-vehicle communications.
Thus, in order to provide cyber security to the modern vehicle, conventionally a technique of HSM (Hardware Security Module) based solution is proposed to implement a secure communication between the two ECUs. For example, modern vehicles contain ECUs that are capable of performing on-board diagnostic (OBD) processes. Vehicles include connectors, such OBD-II and Universal Diagnostic Services (UDS) connectors, that allow external diagnostic tools to be coupled to the vehicle data buses to interact with ECUs. A diagnostic tool may query a vehicle for OBD or UDS test results as well as for real-time data. A diagnostic tool may direct an ECU to perform some action, e.g. a vehicle repair facility may connect to the OBD-II or UDS port to obtain information to determine why a check-engine light is illuminated. Some ECUs, such as the powertrain control module, perform critical functions. These ECUs are secured with HSM based solution to prevent accessing the diagnostic capability without authorization. This technique of HSM based solution enables sandboxing, secure boot, secure software/firmware updates and end-to-end message authentication.
In terms of performing a securing mechanism, this HSM based solution mainly performs two key processes such as an authentication process of authenticating said two ECUs and securely exchanging of messages between two ECUs. In order to perform these two processes, both the ECUs should know the master key first to encrypt and decrypt the messages exchanged between two ECUs and to authenticate themselves with other ECU. Conventionally, in this HSM based solution, this master key is available in separate and dedicated memory chip area of each such ECUs, from where the respective ECUs can

directly access and obtain the master key and perform the above-mentioned secure communication processes using the said master key. However, this approach of providing separate and dedicated memory chip (hardware) to each ECUs is not advisable in terms of cost perspective. Because, each of these dedicated memory chips are costly and vehicle generally have hundreds of ECUs, the cost of providing HSM based solution to all such ECUs would end-up with a cost penalty. Particularly, the HSMs are costlier in the sense that single hardware chip of an ECU cost around 2-3 $ (USD), when multiplied by hundred’s of ECUs gives rise to a significant cost burden to the manufacturer of the vehicle. Because of these limitations and disadvantages, developing a vehicle that is totally composed of such kind of ECUs endowed with HSMs may increment the implementation cost of security measures associated with ECUs.
Further, this HSM based solution is inflexible in terms of in-field configurability. This is because, it is almost impossible to change level of security by changing the security algorithm at run time, as it is fixed in the hardware at the time of manufacturing, so we could not alter it if we find that the security algorithm may not provide best security due to upgraded algorithm used by intruder.
Thus, there is a pressing need for a technique that proves to be the best alternative to the HSM based technique, which is cost effective and flexible in terms of in-field configurability compared to HSM based technique.
SUMMARY OF INVENTION:
The present invention relates to a METHOD AND SYSTEM FOR PERFORMING KEY ENCRYPTION AND CYBER SECURITY IN VEHICLES USING SSM, which provides one more step towards highly secure vehicles by introducing a low cost and in-field configurable or flexible (fully powered/lightweight based on need) software security module which provides ECUs with software-based security that would overcome the above-mentioned limitations and disadvantages of hardware-based solution and that would override some of the features of hardware-based security provided by the hardware

security modules, mentioned below:
i. 128-bit AES hardware accelerator in the HSM module is overridden by software
implementation of AES algorithm in SSM. ii. True random number generator (TRNG) to generate the key in the HSM is
overridden by Deterministic Random Bit Generators (DRBG) implementation in
SSM. iii. Hardware-protected storage of cryptographic keys in HSM is overridden by
Secure key storage with software implementation in SSM.
The motivation for software-based approaches over pure hardware-based approaches is discussed in details eliciting the various requirements and advantages obtained and thus provisioning design rationale.
According to an aspect of present disclosure, method and system are provided for key encryption and cyber security in vehicles using software security module.
According to another aspect of present disclosure, secure key sharing between two or more ECUs is facilitated.
According to another aspect of present disclosure, Secure key (Root of Trust) and the security protocol are updated through a diagnostics tool, which includes but not limited to On board diagnostics services (OBD-II) or Universal Diagnostic Services (UDS), that allows external diagnostic tools to be coupled to the vehicle data buses to interact with ECUs. A diagnostic tool may query a vehicle for OBD or UDS test results as well as for real-time data. Some ECUs, such as the powertrain control module, perform critical functions. As such, those ECUs are secured to prevent accessing the diagnostic capability without authorization.
In a non-limiting embodiment of the present disclosure, the present application discloses a method for securing or encrypting data or other information arising from a user's interaction with software and/or hardware, resulting in transformation of original data into ciphertext. Generally, the ciphertext is generated by the help of context-based keys which

in turn depends on the environment in which the original data was originated and/or was accessed. The ciphertext can be stored in a user's storage device or in an enterprise database (e.g., at-rest encryption) or shared with other users (e.g., cryptographic communication).
In another non-limiting embodiment of the present disclosure, the present application discloses key transport or distribution, i.e. key establishment techniques where one ECU partly creates or otherwise obtains a secret value, and securely transfers it to the other ECU(s). It deals with system and method that encrypt or secure data on a contextual basis using a software-based module, referred as software security module (SSM), that organizes the movement of context-based encryption keys without requiring plaintext access to the keys themselves.
According to an aspect of present disclosure, the software security module, in general, allows enhancement of security related aspects to the ECUs including means and mechanisms to ensure that system by itself and any other authorized accessible member could not compromise on the confidentiality of the protected data.
According to another aspect of present disclosure, it elaborates the software security module based on security algorithms, including but not limited to, AES128, SERPENT, SHA256 and other peer and competent security algorithms. The proposed SSM overpowers HSM in terms of provisioning flexibility, reconfigurability, light-weighted cost effective solution. The crypto algorithms used such as AES-128 and SHA-256 are National Institute of Standards and Technology (NIST) approved crypto algorithms and have proven security parameters.
In a non-limiting embodiment of the present disclosure, the SSM guarantees base level of security by provisioning memory protection. SSM solution dictates that intruders are not able to implant malicious codes, corrupt internet communications and overwrite sensitive parameters, as original key is securely stored in a memory not transferred during the capture process or snipping communication attacks can be avoided serving the security purpose.
The secure repository of the key in a memory includes but not limited to storing the key

in EPROM, EEPROM, NVRAM, flash memory etc. and be implemented as a writable DID (Data Identifier). As mentioned above, the key needs to be stored securely. For securely storing the key, the conventional solution mandates Hardware Security module (HSM) based solution. This might be a computationally effective solution, on the pro side, but at the same time, it is also cost sensitive and non – reconfigurable solution, which may provide no upward compatibility. The present invention deliberates on the SSM based solution to store the secured key. Encryption key can be used for establishing many types of inter ECU communication, which includes but not restricted to challenge - response communication for authenticating the inter-communication between two different ECUs.
To authenticate the inter-communication between two different ECUs, in which, the communication may be regarded as a challenge-response based communication for a smart key vehicle access, a random number is shared and random number needs to be encrypted by both the hardware entities with the help of this encryption key. So, if both the ECUs know the correct encryption key, they will be able to encrypt on the random number sequence in such a way that the information sent from the first ECU will be able to reach to the other ECU in the most secured manner, at first by encryption using a secured key at the transmitting end, sending the encrypted message and decrypting the message at the receiving end. The general process of an example challenge-response communication is depicted as follows:
In order to authenticate ECUs among each other, one ECU manipulates on random number and sends to the other ECU. While sending, the sender ECU encrypts the random number by using a shared encryption key which needs to be secured by using software based solution. ECU also encrypts that the challenge number with the help of same shared encryption key. The receiver ECU after encryption sends it back to the sender ECU and then sender ECU compares with the received encrypted random number. If both gets matched, authentication is done successfully. This device authentication takes place during the start of the vehicle. Here if some problem occurs or if some intruder succeeds to perform some attacks or do some penetration, further progression will get collapsed, and unauthorized access of the vehicle will be given in the hands of intruder. Length of

the encryption key might be 128 or 256 bits. Security access level in terms of read/write access might be provided through a diagnostic service.
The encryption key can be provided with only written security access or with read security access or with write and read security access. Device authentication takes place in random number challenge. The key can be written or read as a DID. It will be done through preferred UDS service. As per specifications some DIDs are only readable, some DIDs are only writable and some of them support both the read and write accesses. In the present invention DIDs with read and write accesses are provided. The confidential fixed bytes used shall be stored in a protected area. Care should be taken that original encryption key value should not get exposed to anyone else during transportation or communication.
Storing key in the plain text format is not a secured way of storing a key, as it is a readable format. The key is encrypted using encryption algorithms like AES, SERPANT etc. The key length might be 128 or 256 bits.
UDS preferred service is also a form of security layer. So, overall present invention proposes a double layer protection. We are encrypting the random numbers. Random number is referred as string. If the string matches, preferred UDS service is getting accessed.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
OBJECTS OF THE DISCLOSURE:
The main object of the present disclosure is to propose a fully powered / lightweight (based on need) software security module as a one-step solution over hardware security module for ensuring and strengthening vehicle security, which provides ECUs with software-based security overriding some of the features of hardware-based security.

Another main object of the present disclosure is to securely share the key between two or more ECUs.
Another object of the present disclosure is to have secure key update through diagnostic tool and easily upgrade in case of any future vulnerability.
BREIF DESCRIPTION OF DRAWINGS
Further aspects and advantages of the present disclosure will be readily understood from the following detailed description with reference to the accompanying drawings. Reference numerals have been used to refer to identical or functionally similar elements. The figures together with a detailed description below, are incorporated in and form part of the specification, and serve to further illustrate the embodiments and explain various principles and advantages, in accordance with the present disclosure wherein:
Fig. 1 illustrate a Flow Diagram for secure key storage and access
Fig. 2 illustrates a diagram depicting Master key encryption, according to an exemplary
aspect of the present disclosure.
Fig. 3(a) illustrates block diagram of a memory where the encrypted key is securely stored
Fig. 3(b) illustrates Master key decryption, according to an exemplary aspect of the
present disclosure.
Fig. 4(a) illustrates key elements of an ECU that implements the method illustrated in the
flow diagram of Fig. 1 and Fig. 5.
Fig. 4(b) illustrates key elements of an ECU that implements the method illustrated in the
flow diagram of Fig. 1 and Fig. 6
Fig. 5 is a flowchart diagram that illustrates a method of operation according to one of the
embodiment of the present disclosure
Fig. 6 is a flowchart diagram that illustrates a method of operation according to another
embodiment of the present disclosure.
It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject

matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION OF THE DISCLOSURE
Referring now to the drawings, there is shown an illustrative embodiment of the disclosure “METHOD AND SYSTEM FOR PERFORMING KEY ENCRYPTION AND CYBER SECURITY IN VEHICLES USING SSM”. It is understood that the disclosure is susceptible to various modifications and alternative forms; specific embodiments thereof have been shown by way of example in the drawings and will be described in detail below. It will be appreciated as the description proceeds that the disclosure may be realized in different embodiments.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.
Fig. 1 depicts flow diagram for such a method of securely generating a master key and exchanging the same between the two ECUs in secured way and on real time basis using Software Security Module (SSM) without storing the master key in advance inside a separate and dedicated memory unlike, HSM based solution.
To achieve this object or purpose, as depicted in Fig. 1, initially at step (101), the first ECU sends a request for master encryption key to a second ECU. In an embodiment the first ECU is a vehicle access ECU and the second ECU is the ECU within a key fob or electronic key or it may be vice versa. Upon receiving the request, the second ECU generates a master encrypted key of a fixed bit length . The steps of generating the master

encryption key of fixed bit length comprises: a step (102) of the generating a hash value of a first fixed bit length for example, 256 bit length from a constant ‘ABC’ based on a first security algorithm for example, SHA 256 algorithm, wherein the constant ‘ABC’ can be of any length and is pre-stored in a hardcoded form within a firmware stored in a memory of the second ECU, and wherein in another embodiment the first bit length may be 192 or 128; step (103) of dividing the generated hash value of 256 bit length into two equal parts to have P1 and P2 of 128 bit each; and a step (104) of generating an encrypted master key from a hardcoded master key of 128 bits stored within a firmware of the memory of second ECU based on a second security algorithm for example, AES 128 algorithm using P1, and storing the encrypted master key in a NVM of the second ECU.
Although, the first security algorithm and the second security algorithms are mentioned as SHA 256 algorithm and AES 128 algorithm respectively in the above description, the same doesn’t limit the scope of the invention and it could be a similar algorithm of any other similar algorithm of any similar type.
The block diagram for performing master key encryption as mentioned above in steps 102-104 is depicted in Fig. 2. Further, the block diagram depicting storage of the master encrypted key in a NVM (flash memory) is illustrated in Fig. 3 (a).
Once the second ECU generates the encrypted master key, at step (105), the master key in the encrypted form is shared to the first ECU from the second ECU via communication medium. In this way, at step (105’), the first ECU obtains or receives the encrypted version of master key from the second ECU in a more secured way as the same has not been sent over the communication medium in plain text form. Upon receiving the encrypted master key from the second ECU, the first ECU decrypts the encrypted master key to generate a master key used for secured communication. The secure communication may be used for authentication, message encryption, signature verification purpose or any similar purpose. This step of generating the master key from the encrypted master key at the first ECU comprises: a step (106) of the generating a hash value of the first fixed bit length for example, 256 bit length from a constant ‘ABC’ based on SHA 256 algorithm, wherein the

constant ‘ABC’ can be of any bit length and is pre-stored in a hardcoded form within a firmware stored in a memory of the second ECU; step (107) of dividing the generated hash value of 256 bit length into two equal parts to have P1 and P2 of 128 bits each; step (108) of generating a master key from the encrypted master key based on AES 128 algorithm and P1; matching the generated master key with a master key stored within the firmware of memory of the first ECU; and establishing said secured communication between first and second ECU, if match is found. The block diagram for generating decrypted form of a master key based on SHA-256 and AES-128 algorithm is depicted in Fig. 3 (b). The first ECU use this master key for various purposes such as for authentication, for encryption (message encryption), for verification (signature verification) etc.
In this way, a master key is generated and exchanged between two ECUs in a secured way on real time basis using Software Security Module (SSM) without storing the master key in advance inside a separate and dedicated memory.
It can be understood that the bit length of hash value is shown to be 256 just for the exemplary purpose. However, the bit length of hash value can be varied based on the requirement. For example, it can be 128 or 192 as well. Similarly, the SHA algorithm (Secure Hash algorithm) can also be chosen based on the first fixed bit length of the hash value. For example, for 128 hash value bit length SHA 128 can be chosen and for 192 hash value bit length SHA 192 can be chosen. Similarly, the AES algorithm type is selected based on the second fixed length.
Fig. 4a and Fig. 4b depict the structure of the first and the second ECU as mentioned above. As mentioned in Fig. 4a, the first ECU (400 a) comprises a processor (401a) and a memory (402a). Similarly, as mentioned in Fig. 4b the second ECU (400b) comprises a processor (401b) and a memory (402b). The processor of first ECU configured to perform the method steps 101-105. Similarly, the processor of second ECU configured to perform the methos steps 106-108.

Fig. 5 & 6 are flowchart diagrams that illustrate a method of operation of different embodiments of this disclosure. Particularly, Fig. 5 & Fig. 6 explain the method of Fig. 1 in flowchart format. Since, steps of Fig. 5 & Fig. 6 are substantially same as that of the steps described above in Fig. 1, repetition of the same is avoided here for the sake of brevity.
The order in which the various operations of the method are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof.
The various operations of method described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and/or software component(s) and/or module(s), including, but not limited to the processor (401) of Figure 4. Generally, where there are operations illustrated in Figures, those operations may have corresponding counterpart means-plus-function components.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on 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(s) 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, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

Certain aspects may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may comprise a computer readable media having instructions stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. For certain aspects, the computer program product may include packaging material.
The terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless expressly specified otherwise.
Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention.
The foregoing description of the various embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to limit the embodiments shown herein, and instead the embodiments should be accorded the widest scope consistent with the principles and novel features disclosed herein.

WE CLAIM:
1. A method of communication between two ECUs (Electronic Control Units) of an automobile
comprising:
receiving (101) a request for sending a master key from a first ECU to a second ECU;
generating (102), at the second ECU, a hash value of a first fixed bit length from a constant of any bit length based on a first security algorithm;
disintegrating (103), at the second ECU, the generated hash value of a first fixed length into two parts to have P1 and P2 each having a second fixed bit length halve than the first fixed bit length;
generating (104), at the second ECU, an encrypted master key of second fixed bit length based on P1 and a second security algorithm; and
transmitting (105) said encrypted master key from the second ECU to the first ECU.
2. The method as claimed in claim 1 further comprises:
receiving (105’) at the first ECU, an encrypted master key of second fixed bit length at the first ECU from the second ECU;
generating (106), at the first ECU, a hash value of the first fixed bit length from the constant of any bit length based on the first Security algorithm;
disintegrating (107), at the first ECU, the generated hash value of a first fixed length into two parts to have P1 and P2 each having the second fixed bit length halve than the first fixed bit length; and
decrypting (108), at the first ECU, the received encrypted master key based on P1 and the constant using the second security algorithm to generate a master key.
3. The method as claimed in claim 2 further comprises:
establishing communication by the first ECU with the second ECU using said decrypted master key for authentication, message encryption and signature verification purpose based on matching the generated master key with a master key stored within the firmware of the memory of the first ECU.

4. The method as claimed in claim 1 wherein, the constant is of any arbitrary bit length and is pre-stored in a hardcoded form within the memory of the second ECU.
5. The method as claimed in claim 2 wherein, the constant is of any bit length and is pre-stored in a hardcoded form within a firmware of a memory of the first ECU.
6. The method as claimed in claim 1 wherein, the first fixed bit length is 128, 192 or 256 and wherein the type of the first security algorithm is selected based on the first fixed length.
7. The method as claimed in claim 1 wherein, the second security algorithm type is selected based on the second fixed length.
8. The method as claimed in claim 1 wherein, the first and second ECUs are SSM (Software Security Module) enabled ECUs.
9. The method as claimed in claim 1 wherein, the first and second ECUs includes but not limited to vehicle access ECU within the vehicle and ECU of the key fob or electronic key respectively.10. The method as claimed in claim 1, wherein the encrypted master key is stored within a memory of the second ECU.
11. An ECU of an automobile comprises:
a processor; and
a memory coupled to the processor wherein the processor configured to:
receive a request for sending a master key from another ECU;
generate a hash value of a first fixed bit length from a constant of any bit length based on a first security algorithm;
disintegrate the generated hash value of a first fixed length into two parts to have P1 and P2 each having a second fixed bit length halve than the first fixed bit length;
generate an encrypted master key of second fixed bit length based on P1 and AES algorithm; and
transmit said encrypted master key from the second ECU to the first ECU.
12. The ECU as claimed in claim 1 wherein the memory is configured to pre-store the constant
of any arbitrary bit length in a hardcoded form within its firmware.

13. The ECU as claimed in claim 1, wherein the memory is further configured to store the encrypted master key.
14. The ECU as claimed in claim 1, wherein the first security algorithm includes but not limited to a Security Hash Algorithm (SHA), wherein the second security algorithm includes but not limited to AES(Advanced Encryption Standard).
15. An ECU of an automobile comprises: a processor; and
a memory coupled to the processor wherein the processor configured to:
receive an encrypted master key of a second fixed bit length from another ECU, wherein the master key is encrypted based on P1 and a constant using AES algorithm;
generate a hash value of a first fixed bit length from the constant of any bit length based on the first security algorithm;
disintegrating (107) the generated hash value of the first fixed length into two parts to have P1 and P2 each having the second fixed bit length halve than the first fixed bit length; and
generating a decrypted master key from the encrypted master key based on said P1 and the constant using the second security algorithm.
16. The ECU of the automobile, wherein the processor further configured to establish
communication with the another ECU using said decrypted master key for authentication, message
encryption and signature verification purpose.
17. The ECU of the automobile, wherein the memory is configured to pre-store the constant of any bit
length in a hardcoded form within its firmware.