The present disclosure relates to embedded system security and in particular relates to a secure and remote updating of the embedded systems.

BACKGROUND
In modern times, automotive ECUs play a vital role. A vehicle can have more than 70 ECUs fitted at a time. Every ECU has a specific task to be performed and it has an ECU Firmware (FW) running over it. A standard firmware upgrade mechanism is used to upgrade a firmware of the ECUs mounted on vehicle, for example to make firmware more concrete.

As referred in Fig. 1, a mechanism “Firmware Over the air (FOTA)” has been into practice for some time. As a part of said system, a Build system or simply a build server builds a new firmware and calculates its checksum “CRC32”. Such CRC32 is prepended to Firmware and uploaded to a fleet management server hosted over cloud. Via said fleet management, new firmware is downloaded on a remote device using modem. During said FOTA, the build server first shares CRC32 of new Firmware and then starts transferring actual Firmware. As referred in Fig. 1, the new firmware is downloaded in a dedicated download area over external flash forming a part of vehicle’s ECU, along with CRC32.

A bootloader forming a part of the vehicle ECU calculates CRC32 of new Firmware and verifies it with the CRC32 shared by FOTA server. This step assures integrity of the download. Once integrity check is successful, new firmware will be installed in internal flash forming a part of the vehicle ECU and set as Active firmware.

CRC32 (check sum) refers a mechanism to identify bit flips. Any attacker or hacker can create a malicious firmware that calculates particular CRC. At least there does not exist any secure channel to ensure security during firmware over the air (FOTA) update. Any attacker can easily flash malicious firmware with a counterfeit or unauthorized CRC and manipulate the configuration of the ECU of the vehicle.

At least due to aforesaid, the authenticity of newly downloaded Firmware is at risk. If device is enabled to update data over Controller Area Network (CAN bus), then such malicious firmware can damage the entire ecosystem of the vehicle at least by flooding spurious or garbled CAN messages. Overall, the state-of-the-art environments defined in Fig. 1 pose a huge risk for various avenues and especially critical systems like Automotive.

There lies at least a need to maintain authenticity of new firmware, assure integrity and confidentiality. There lies at least a need to thwart any attacker attempt of injecting malicious firmware which jeopardizes the vehicular operation and cause life threatening scenarios.

SUMMARY
This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.

The present subject matter refers a method for securing a device-executable model for communication within a client-server-based networking environment. The method comprises generating one or more of a hash identifiers and a signature for a raw-model with a first private key and a cryptographic hash engine encrypting the raw-model into an encrypted model based on a symmetric key. A hash-based identifier is generated for the encrypted model based on said cryptographic engine. A package is created, wherein the package comprises the encrypted model prepended with a header representing the encrypted model, said header comprising one or more of: a) the signature for a raw-model, b) the hash based identifier for the raw model and, c) the hash based identifier for the encrypted model. A signature is generated for the header based on a second private key and the cryptographic hash engine and thereby said signature for the header is also incorporated within the header.

In another embodiment, a method for securely downloading of an executable model upon a client-server based networking environment is provided. The method comprises downloading from a remote server, to an external memory of client device, a package comprising an encrypted model prepended with a header. A hash identifier is generated with respect to the header based on a cryptographic hash engine. A signature is calculated based on the hash identifier of the header and a pre-stored public key associated with the header. The calculated signature is verified with a pre-stored header signature within the header. Based on said verification of the signature, a hash identifier is generated with respect to the encrypted model based on a cryptographic hash engine available with a trust anchor within the client device. The calculated hash identifier is verified with a pre-stored header identifier within the header. Based on said verification of the hash identifier of the encrypted model, integrity of the downloaded model is established and thereby a safe installation of the downloaded model is pursued upon the client device.

To further clarify advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Figure 1 illustrates a state of the procedure;
Figure 2 illustrates method steps, according to an embodiment of the present disclosure;
Figure 3 illustrates method steps, according to another embodiment of the present disclosure;
Figure 4 illustrates a build server based secure package creation, according to an embodiment of the present disclosure;
Figure 5 illustrates a bootloader based installation and booting of the firmware, according to an embodiment of the present disclosure; and
Figure 6 illustrates a computing architecture of the ECU, according to an embodiment of the present disclosure.

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

DETAILED DESCRIPTION OF FIGURES
For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.
It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.
Reference throughout this specification to “an aspect”, “another aspect” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase “in an embodiment”, “in another embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skilled in the art to which this invention belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

Figure 2 illustrates a method for securing a device-executable model for communication within a client-server based networking environment. The method comprises generating (Step 202) one or more of a hash identifier and a signature for a raw-model with a first private key and a cryptographic hash engine encrypting the raw-model into an encrypted model based on a symmetric key. The cryptographic hash engine corresponds to a cryptographic python engine function. For such purposes, the first and second private key, and the symmetric key are received from a trusted hardware source (i.e. trusted hardware dongle) located at the server-end. The counterpart keys may be sent to a trust anchor within a client device. Such counterpart keys may be defined as one or more of first and second public keys related to the first and second private key, and a replica key of the symmetric key used for encrypting the model.
In an example, the first public and the first private key correspond to the signature of the raw model and are defined by a BOOT public key and a BOOT private key, respectively. The second public and the second private key corresponding to the signature of the header are defined by a firmware over the air (FOTA) public key and the FOTA private key, respectively. Said BOOT and FOTA asymmetric key pairs are received from an OEM. The private keys from the received pairs are stored on the build server as the first and second private keys. The public keys from the received pairs and a received symmetric key are provisioned upon a trust-anchor embedded on an ECU of the client device.

Further, the method comprises generating (step 204) a hash based identifier for the encrypted model based on said cryptographic engine. Thereafter, a package comprising the encrypted model prepended with a header representing the encrypted model is created (step 206). The header comprises one or more of: a) the signature for a raw-model, b) the hash based identifier for the raw model and c) the hash based identifier for the encrypted model. Further, the method comprises generating (step 208) a signature for the header based on a second private key and the cryptographic hash engine and thereby incorporating said signature for the header within the header itself.

Further, the method comprises sending (step 210) the package from a build-server to a client device through a wireless communication for enabling OTA (Over-the-Air programming), wherein such wireless communication corresponds to a protocol defined by HTTPS or FTPS.

Figure 3 illustrates a method for securely downloading of an executable model upon a client device within a client-server based networking environment. The method comprises downloading (step 302) from a remote server, to an external memory of client device, a package comprising an encrypted model prepended with a header. Thereafter the method comprises generating (step 304) a hash identifier with respect to the header based on a cryptographic hash engine. Thereafter the method comprises calculating (step 306) a signature based on the hash identifier of the header and a pre-stored public key associated with the header. Thereafter the method comprises verifying (step 308) the calculated signature with a pre-stored header signature within the header. Based on said verification of the signature, a hash identifier is generated (step 310) with respect to the encrypted model based on a cryptographic hash engine available with a trust anchor within the client device.

Thereafter, the method comprises (step 312) verifying the calculated hash identifier with a pre-stored header identifier within the header. Based on said verification of the hash identifier of the encrypted model, integrity of the downloaded model is established and the installation (step 314) of the downloaded model is done upon the client device. The installation comprises erasing a pre-stored model within an internal memory and transferring the header of the encrypted model from the external memory into the internal memory. Thereafter, the encrypted model is decrypted based on a pre-stored symmetric key to obtain a raw model and the decrypted raw model is installed in the internal memory.

Figure 4 illustrates a FOTA package creation flow and refers to the steps 202 till 210 of Fig. 2.

With respect to Fig. 4a, at step 402, for the purposes of later enabling a cryptographic signature generation, a pair of public and private is generated in a controlled secure environment by OEM. A symmetric key is generated in a secure and controlled environment by OEM. At step 402a , a private key and a a symmetric key is placed on a trusted hardware “Dongle” at a build-server or IoT server. At step 402b depicted later in Fig. 5, a public key and the symmetric key are provisioned on device during production.

More specifically, OEM generates symmetric key for firmware-encryption. This key is available at a production server (i.e. car manufacturer) as well as FOTA build server. A symmetric key will be common across all devices manufactured and used for Firmware encryption and decryption.

The following table 1 summarizes the aforesaid key storage as BOOT, FOTA and the symmetric key.
Table 1
Keys Storage (Step 402a) Storage (Step 402b)
Symmetric key 1. At server with Trusted Hardware Dongle
2. Provisiosned on device during production
Public and Private Key pair 1 1. Boot Private key at server with Trusted Hardware Dongle
2. Boot Public key provisioned on device during production
Public and Private Key pair 2 1. FOTA Private key at server with Trusted Hardware Dongle
2. FOTA Public key provisioned on device during production

At step 404, a raw firmware is provided at the build server end for encryption.

At step 406, the private keys and symmetric keys are provided for facilitating encryption and signature generation.

At step 408, which corresponds to step 202, a Raw Firmware is encrypted using a python cryptographic engine.

At step 410, a secure FOTA package is created based on steps 204, 206 and 208. Alternatively, raw firmware is turned in to a Secure FOTA package, using a python cryptographic engine. Another input to this engine is cryptographic keys (FOTA and BOOT private keys) from trusted hardware dongle. An encrypted firmware with symmetric key is prepended with a fixed size firmware header.

The package comprises firmware header and the encrypted new firmware. The header itself comprises a) the signature for a raw-model, b) the hash based identifier for the raw model, c) the hash based identifier for the encrypted model and, d) the signature for the header.

In an example as shown in Fig. 4b, the firmware header within the secure package contains a) Raw and Encrypted Firmware Hash, b) Raw Firmware signature generated using BOOT private key, and Firmware header signature generated using FOTA private key. The remaining part of the package comprises the encrypted firmware.

At step 412, which corresponds to step 210, the secure FOTA package is communicated over the air (OTA) using secure communication channel like HTTPs or FTPs through a cloud fleet management network or simply based on cloud server.

Figure 5 refers downloading and installation of the package on-device communicated vide step 412.

Step 502 corresponds to on-device provisioning of public keys (FOTA and BOOT) and symmetric key vide step 402b as referred in Fig. 4 Specifically, during device manufacturing, symmetric and public keys are provisioned on a “Trust anchor”.

Step 504 corresponds to installation of the ECU within the actual utility (say car or any other vehicle). Trust anchor is embedded on the ECU device. In addition, the ECU comprises the bootloader and optionally an existing copy of firmware in the internal flash.
Step 506 corresponds to external flash operation upon receipt of the secure package through step 412. More specifically, step 506 corresponds to the operation of steps 302 till 314. The provisioned keys within the trust anchor are used by Secure bootloader to authenticate a new Firmware downloaded on device.
More specifically as a part of step 506, following are sub-steps:
a) The bootloader calculates signature of downloaded package (present within the external flash) using FOTA public key and SHA256 (i.e. hash) of the header, and the calculated signature is verified with header signature present in Firmware Header.
b) Once verified, the bootloader calculates SHA256 of the encrypted FW binary. The same is verified with SHA256 present in the FW header. Based thereupon, a Firmware is decrypted and installed in internal flash as referred in next step 508.
Step 508 corresponds to an internal flash operation and corresponds to installation operation. The installation comprises erasing a pre-stored model within an internal memory and transferring the header of the encrypted model from the external memory into the internal memory. Thereafter, the encrypted model is decrypted based on a pre-stored symmetric key to obtain a raw model and the decrypted raw model is installed in the internal memory.
More specifically, as the firmware stood encrypted with Symmetric key in Fig. 4 during creation of the package, now the same symmetric key is used to decrypt firmware in step 508. Accordingly, the firmware is decrypted and installed in internal flash
Fig. 5b illustrates an extended operation of step 508 as following steps 602 till 610 with respect to every booting event of the client device.
At step 602, the installed model within the internal flash memory is configured to re-execute the steps 304 till 308 ( or sub-step (a) of step 506) for verifying the calculated signature with a pre-stored header signature within the header, i.e. for verifying FW header signature with FOTA public key.
At step 604, based on said verification of the signature and in continuation to the same boot, the bootloader calculates SHA256 hash of active Firmware and generates it's signature using BOOT public key. This signature is cross verified with signature generated by the build server with BOOT private key. More specifically, the bootloader generates a hash identifier with respect to the raw model based on the cryptographic hash engine. In other words, SHA256 of decrypted FW (RAW binary) present in internal flash is calculated. The same is verified with the SHA256 present in FW header for integrity check of active FW.

At step 606, a signature is calculated for the raw model based on a pre-stored public key (BOOT public key) associated with the raw model and the generated hash identifier (the generated SHA 256 of decrypted firmware in preceding step 604) for the raw model.

At step 608, the calculated signature for the raw model is verified with a pre-stored signature associated with the raw model within the header to thereby conclude a security check of the raw model in the internal memory.

At step 610, based on upon conclusion of security and in continuation to the present step 508, the booting of the raw model is allowed within the internal flash by the boot-loader. Accordingly, for execution of the raw model by the ECU, the control is transferred from the bootloader.

Fig. 6 shows yet another exemplary implementation in accordance with the embodiment of the invention, and yet another typical hardware configuration of the ECU referred in preceding figures in the form of a computer system 800. The computer system 800 can include a set of instructions that can be executed to cause the computer system 800 to perform any one or more of the methods disclosed. The computer system 800 may operate as a standalone device or may be connected, e.g., using a network, to other computer systems or peripheral devices.
In a networked deployment, the computer system 800 may operate in the capacity of a server or as a client user computer in a server-client user network environment, or as a peer computer system in a peer-to-peer (or distributed) network environment. The computer system 800 can also be implemented as or incorporated across various devices, such as a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a land-line telephone, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single computer system 800 is illustrated, the term "system" shall also be taken to include any collection of systems or sub-systems that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.
The computer system 800 may include a processor 802 e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both. The processor 802 may be a component in a variety of systems. For example, the processor 802 may be part of a standard personal computer or a workstation. The processor 802 may be one or more general processors, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analysing and processing data. The processor 802 may implement a software program, such as code generated manually (i.e., programmed).
The computer system 800 may include a memory 804, such as a memory 804 that can communicate via a bus 808. The memory 804 may include, but is not limited to computer-readable storage media such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, memory 804 includes a cache or random access memory for the processor 802. In alternative examples, the memory 804 is separate from the processor 802, such as a cache memory of a processor, the system memory, or other memory. The memory 804 may be an external storage device or database for storing data. The memory 804 is operable to store instructions executable by the processor 802. The functions, acts or tasks illustrated in the figures or described may be performed by the programmed processor 802 for executing the instructions stored in the memory 804. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro-code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.
As shown, the computer system 800 may or may not further include a display unit 810, such as a liquid crystal display (LCD), an organic light-emitting diode (OLED), a flat panel display, a solid-state display, a cathode ray tube (CRT), a projector, a printer or other now known or later developed display device for outputting determined information. The display 810 may act as an interface for the user to see the functioning of the processor 802, or specifically as an interface with the software stored in the memory 804 or in the drive unit 816.
Additionally, the computer system 800 may include an input device 812 configured to allow a user to interact with any of the components of system 800. The computer system 800 may also include a disk or optical drive unit 816. The disk drive unit 816 may include a computer-readable medium 822 in which one or more sets of instructions 824, e.g. software, can be embedded. Further, the instructions 824 may embody one or more of the methods or logic as described. In a particular example, the instructions 824 may reside completely, or at least partially, within the memory 804 or within the processor 802 during execution by the computer system 800.
The present invention contemplates a computer-readable medium that includes instructions 824 or receives and executes instructions 824 responsive to a propagated signal so that a device connected to a network 826 can communicate voice, video, audio, images or any other data over the network 826. Further, the instructions 824 may be transmitted or received over the network 826 via a communication port or interface 820 or using a bus 808. The communication port or interface 820 may be a part of the processor 802 or maybe a separate component. The communication port 820 may be created in software or maybe a physical connection in hardware. The communication port 820 may be configured to connect with a network 826, external media, the display 810, or any other components in system 800, or combinations thereof. The connection with the network 826 may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed later. Likewise, the additional connections with other components of the system 800 may be physical connections or may be established wirelessly. The network 826 may alternatively be directly connected to the bus 808.
The network 826 may include wired networks, wireless networks, Ethernet AVB networks, or combinations thereof. The wireless network may be a cellular telephone network, an 802.11, 802.16, 802.20, 802.1Q or WiMax network. Further, the network 826 may be a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols. The system is not limited to operation with any particular standards and protocols. For example, standards for Internet and other packet-switched network transmission (e.g., TCP/IP, UDP/IP, HTML, and HTTP) may be used.
Overall, at least by virtue of aforesaid, the present subject matter renders the following advantages:
• Trusted Firmware will be allowed to run on ECU.
• Firmware confidentiality is maintained using Symmetric key encryption.
• Authenticity of the Firmware is achieved using FOTA and BOOT asymmetric key mechanisms.
• Using Trusted Hardware Dongle at build system assures secrecy of Symmetric and Private key during production and Firmware release to fleet management server.
• All keys are pre-provisioned in Trust Anchor and TA is embedded on ECU device during production. This at least assures security of keys over device on field.
• On every consecutive boot, bootloader verifies signature of active Firmware. Hence, no malicious firmware will be allowed to run on device.
• A channel to download Firmware on device is secure one i.e. HTTPS or FTPS, hence attacker will not be able to download malicious Firmware on device.
• The aforesaid security measures assure safe and protected vehicle eco system.

Overall, the present subject matter renders a secure boot and secure firmware update for embedded systems. As authenticity, integrity and confidentiality are three major constructs of security of any embedded system, the present subject matter proposes achieving these constructs with assuring confidentiality of cryptographic keys (private, public and symmetric keys). Last but not the least, the present subject matter renders a highly secure, efficient environment for an end customer’s product and in example creates a safe automotive eco system for mankind.

While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to the problem and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

Claims:1. A method for securing a device-executable model for communication within a client-server based networking environment comprising:
Generating (202) one or more of a hash identifier and a signature for a raw-model with a first private key and a cryptographic hash engine encrypting the raw-model into an encrypted model based on a symmetric key;
Generating (204) a hash based identifier for the encrypted model based on said cryptographic engine;
Creating (206) a package comprising the encrypted model prepended with a header representing the encrypted model, said header comprising one or more of:
a) the signature for a raw-model;
b) the hash based identifier for the raw model and
c) the hash based identifier for the encrypted model
generating (208) a signature for the header based on a second private key and the cryptographic hash engine and thereby incorporating said signature for the header within the header.

2. The method as claimed in claim 1, further comprising:
Sending (210) the package from a build-server to a client device through a wireless communication for enabling OTA (Over-the-Air programming), wherein said cryptographic hash engine corresponds to a cryptographic python engine function for creating said package comprising said encrypted model prepended with header and said wireless communication corresponds to a protocol defined by HTTPS or FTPS

3. The method as claimed in claim 1, further comprising:
receiving the first and second private key and the symmetric key from a trusted hardware source located at the server-end;
sending counterpart keys to a trust anchor within the client device, said counterpart keys defined as one or more of:
first and second public keys related to the first and second private key;
a replica of symmetric key used for encrypting the model.
4. The method as claimed in claim 1, wherein the first public and the first private key corresponding to the signature of the raw model are defined by a BOOT public key and a BOOT private key, respectively.

5. The method as claimed in claim 1, wherein the second public and the second private key corresponding to the signature of the header are defined by a firmware over the air (FOTA) public key and the FOTA private key, respectively.

6. The method as claimed in claims 4 and 5, further comprising:
receiving said BOOT and FOTA asymmetric key pairs from an OEM;
storing private keys from the received pairs on the build server as the first and second private keys; and
provisioning public keys from the received pairs and a received symmetric key upon the trust anchor embedded on an ECU of the client device.

7. A method for securely downloading of an executable model upon a client-server based networking environment, said method comprising:
Downloading (302) from a remote server, to an external memory of client device, a package comprising an encrypted model prepended with a header;
Generating (304) a hash identifier with respect to the header based on a cryptographic hash engine;
Calculating (306) a signature based on the hash identifier of the header and a pre-stored public key associated with the header;
Verifying (308) the calculated signature with a pre-stored header signature within the header;
based on said verification of the signature, generating (310) a hash identifier with respect to the encrypted model based on a cryptographic hash engine available with a trust anchor within the client device;
verifying (312) the calculated hash identifier with a pre-stored header identifier within the header; and
based on said verification of the hash identifier of the encrypted model, establishing (314) integrity of the downloaded model and thereby allowing installation of the downloaded model upon the client device.

8. The method as claimed in claim 7, wherein said installation comprises:
erasing a pre-stored model within an internal memory and transferring the header of the encrypted model from the external memory into the internal memory;
decrypting the encrypted model based on a pre-stored symmetric key to obtain a raw model and installing the decrypted raw model in the internal memory.

9. The method as claimed in claim 8, further comprising, with respect to every booting event of the client device, performing upon the installed model within the internal memory the steps of:
Generating (304) a hash identifier with respect to the header based on a cryptographic hash engine;
Calculating (306) a signature based on the hash identifier of the header and the pre-stored public key associated with the header, said pre-stored public key associated with the header corresponding to a firmware over the (FOTA) public key ;
Verifying (308) the calculated signature with a pre-stored header signature within the header;
based on said verification of the signature, generating (604) a hash identifier with respect to the raw model based on the cryptographic hash engine;
Calculating (606) a signature for the raw model based on a pre-stored public key associated with the raw model and the generated hash identifier for the raw model, said pre-stored public key associated with the raw model corresponding to a boot public key; and
Verifying (608) the calculated signature for the raw model with a pre-stored signature associated with the raw model within the header to thereby conclude a security check of the raw model in the internal memory.

10. The method as claimed in claim 9, further comprising
allowing booting (610) of the raw model within the internal flash by a boot-loader based on said verification of calculated signature of the raw model; and
transferring control from bootloader to an execution of the raw model by an ECU forming a part of the client device.