DESC:FIELD OF INVENTION
[0001] The present disclosure relates generally to a system and a method for verification of integrity at periodic intervals and on-demand by a user at runtime of an embedded hardware in the computer field. The disclosure, more particularly, relates to integrity verification for detecting changes in currently running system using the hashes generated at the second stage boot loader.

BACKGROUND
[0001] Many organizations are providing portable devices (e.g., laptops, tablets, mobiles etc.) to employees. However, allowing employees to access services through portable devices has increased the organization’s exposure to potential security breaches. For example, if an employee lost portable device, an unauthorized party could retrieve any unsecured data on the portable device. In order to mitigate this type of unauthorized access, many organizations use portable device management policies to restrict control of the portable devices and thereby reduce potential security risks for portable devices that are capable of connecting to services within the organization. There are various means by which the portable device data can be protected from the unauthorized access.
[0002] US20140281539A1 discloses systems and methods for a secure mobile framework to securely connect applications running on mobile devices to services within an enterprise are provided. Various embodiments provide mechanisms of securitizing data and communication between mobile devices and end point services accessed from a gateway of responsible authorization, authentication, anomaly detection, fraud detection, and policy management. Some embodiments provide for the integration of server and client-side security mechanisms, and for the binding of a user/application/device to an endpoint service along with multiple encryption mechanisms. For example, the secure mobile framework provides a secure container on the mobile device, secure files, a virtual file system partition, a multiple level authentication approach (e.g., to access a secure container on the mobile device and to access enterprise services), and a server side fraud detection system. In some embodiments, the multiple level authentication approach can include an operating system integrity check as part of the secure mobile framework.
[0003] RU2396594C2 discloses method for protected booting of computer operating system with integrity check includes stages of operating system boot loader start-up, reading coding key, checking integrity of operating system, and booting of operating system. The boot loader is previously recorded on external media. All sectors of computer hard disk are coded at initial stage of booting. Prior to operating system integrity check, coding key required for this check and further booting is read. The coding key is previously saved in protected memory of external media. The user authentication is required for access to external device memory.
[0004] US10114949B2 discloses various embodiments are generally directed to techniques for monitoring the integrity of an operating system (OS) security routine that checks the integrity of an OS and/or one or more application routines. An apparatus may include a first processor component to execute an operating system (OS) in a first operating environment within a processing device and to execute an OS security routine to recurringly verify an integrity of the OS. A challenge component within a second operating environment within the processing device that is isolated from the first operating environment to recurringly challenge the OS security routine to provide a measure of itself and a response component within the second operating environment to analyse each measure provided by the OS security routine and an elapsed time to receive each measure from the OS security routine to verify an integrity of the OS security routine.
[0005] WO2007045133A1 discloses a computer system and a method which can perform integrity checking include: a run mode unit, which includes a integrity checking booting up controlling value, is checked to determine whether starting up in the integrity checking booting up mode; an EFI integrity checking unit (5), checking the integrity of the EFI imaging code; and the EFI integrity checking unit (5) comprises an EFI integrity measuring value. After the calculated value for the integrity of the EFI is generated, the integrity of the EFI imaging code can be determined by comparing the measuring value with the calculated value. The system also includes an operating system integrity checking unit (6) and a integrity managing unit. The system and the method are based on the EFI BIOS, and perform the integrity checking against the operating system during the low level firmware of the computer is running, thus have the better reliability and security.
[0002] US10073966B2 discloses an integrity verification subsystem can verify the integrity of software and firmware modules on a computing device at load time and/or at run time, independently of any operating systems that may be installed on the computing device. Some versions of the integrity verification subsystem can operate in physical and/or virtualized system environments, including virtualized mobile device architectures.
[0003] Therefore, there is still a need of an invention which solves the above defined problems and provide a system and a method for integrity verification for detecting changes in currently running system or embedded hardware.

SUMMARY
[0004] This summary is provided to introduce concepts related to verification of integrity of an embedded hardware at periodic intervals and on-demand by a user at runtime. This summary is neither intended to identify essential features of the present invention nor is it intended for use in determining or limiting the scope of the present invention.
[0005] In an embodiment of the present invention, a method for integrity checking of an embedded hardware is provided. This method includes generating a plurality of hashes for a plurality of system modules by a processor. It further includes storing the generated hashes of the system modules by a trusted memory. Further, the method includes analysing the generated hashes stored in the trusted memory by the processor and calculating the plurality of hashes of the plurality of system modules by the processor. Furthermore, the method includes verifying the calculated hashes of the system modules with the generated hashes of the system modules stored in the trusted memory at periodic intervals by the processor.
[0006] In another embodiment of the present invention, a system for integrity checking of an embedded hardware is provided. This system includes a processor wherein said processor is connected to a memory, a process wherein the process is a system service that runs in the processor and communicates with the memory. The system further includes a controller to store a plurality of secure data and it also includes a trusted memory located in the controller. The trusted memory stores the plurality of secure data wherein the processor generates a plurality of hashes for a plurality of system modules. This trusted memory stores the generated hashes of the system modules for integrity checking at periodic intervals and on-demand by a user at runtime. The processor analyses the generated hashes stored in the trusted memory and it calculates the plurality of hashes of the plurality of system modules. The processor further verifies the calculated hashes of the system modules with the generated hashes of the system modules stored in the trusted memory at periodic intervals and on-demand by the user at runtime.
[0007] In another embodiment, if the integrity verification of any of the plurality of system modules fails, the method includes blocking the further integrity checking of the other modules by the processor and erasing all the sensitive and secure data stored in the trusted memory by the processor.
[0008] In yet another embodiment, if the integrity verification of any of the plurality of system modules is achieved, the method includes permitting communication with the system modules by a user by the processor.
[0009] In yet another embodiment, wherein the plurality of system modules includes trusted controller firmware, executable images, and itself.
[0010] In yet another embodiment, the method also includes encrypting the generated hashes of the system modules before storing in the trusted memory by a controller.
[0011] In yet another embodiment, the method also includes decrypting the hashes stored in the trusted memory and sending the decrypted hashes to the processor for integrity checking by the controller.
[0012] In yet another embodiment, the method also includes on-demand integrity checking of the system modules, wherein said on-demand integrity checking is performed by the user.
[0013] In yet another embodiment, the method also includes retrieving the stored hashes from the trusted memory for performing the integrity checking of the system modules by the processor.
[0014] In yet another embodiment, the method also includes performing integrity checking at periodic intervals for the system modules by the processor, wherein the periodic intervals at which the integrity checking is performed is configured by the user.
[0015] In yet another embodiment, the method also includes accessing the trusted memory only after said trusted memory is authenticated by the controller.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
[0016] The detailed description is described with reference to the accompanying figures.
[0017] Figure 1 illustrates an exemplary block diagram of a computing device on which the system and method provided herein may be implemented, in accordance with an embodiment of the present invention.
[0018] Figure 2 illustrates a flowchart of the process of generating the hashes for trusted controller firmware, executable images, self by the system service at a second stage boot loader, in accordance with an embodiment of the present invention.
[0019] Figure 3 illustrates a flowchart of the process of integrity checking at a second stage boot loader by the system service, in accordance with an embodiment of the present invention.
[0020] Figure 4 illustrates a process of verifying the integrity of the system modules at periodic intervals by the processor, in accordance with an embodiment of the present invention.
[0021] Figure 5 illustrates a flowchart of a method for integrity checking of an embedded hardware, in accordance with an embodiment of the present invention.
[0022] 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 invention. Similarly, it will be appreciated that any flow chart, flow diagram, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION
[0023] The various embodiments of the present invention provides a method and a system for integrity checking of an embedded hardware.
[0024] In the following description, for purpose of explanation, specific details are set forth in order to provide an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these details.
[0025] One skilled in the art will recognize that embodiments of the present invention, some of which are described below, may be incorporated into a number of systems.
[0026] However, the device is not limited to the specific embodiments described herein. Further, structures and devices shown in the figures are illustrative of exemplary embodiments of the present invention and are meant to avoid obscuring of the present invention.
[0027] Furthermore, connections between components and/or modules within the figures are not intended to be limited to direct connections. Rather, these components and modules may be modified, re-formatted or otherwise changed by intermediary components and modules.
[0028] The appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
[0029] The present invention provides integrity verification and authentication of a plurality of system modules and itself by the system service. The subject matter disclosed in the present disclosure provides protection to the system modules from integrity failure and to be used in devices including computers, embedded devices, cell phones, devices having limited computing power, devices having limited storage power, etc. The present disclosure also discloses about protecting the integrity of the system against misuse by unauthorized person or entities. The system service is invoked at the second stage boot loader and if the integrity of the running system modules is found to be integrity failed, further integrity checking stops and the system service starts erasing the sensitive data stored in the trusted memory. The system may be powered off to avoid further usage.
[0030] In an embodiment, the method involves generating the hashes of the running system modules such as trusted controller firmware, executable images, and itself by the system service. The system service includes functionality that determines the hashes of the current running system modules on first boot of the system. The system service stores the generated hashes of all the modules in trusted memory of controller for integrity checking of system in subsequent boot.
[0031] In another embodiment, the method involves verifying integrity of the system modules. The system service checks the integrity of the system modules periodically, if the integrity of any of the module is failed then immediately the system service erases all the sensitive data stored in the trusted memory. The trusted memory can be accessed only after the communicating application authenticates itself with the controller. The system service accesses the stored data in the trusted memory after it is authenticated by the controller. Thereafter, the system service retrieves the stored hashes from the trusted memory to perform the integrity checking of the system modules.
[0032] In yet another embodiment, the method provides integrity checking of the current running system using the first boot time generated hashes.
[0033] In yet another embodiment, the method provides calculating the hashes of the running system modules by the system service and verifying with the stored hashes in the trusted memory.
[0034] In yet another embodiment, the method provides periodic integrity checking of the running system. The periodic integrity checking is performed by comparing the calculated hashes at runtime with the stored hashes from the trusted memory.
[0035] In yet another embodiment, the method provides on-demand integrity checking of the running system. The on-demand integrity checking is performed by the user to check that the running system is intact.
[0036] Figure 1 illustrates an exemplary block diagram of a computing device on which the system and method provided herein may be implemented, according to an embodiment of the present disclosure. The system 100 includes a processor 110 connected to a memory 120. The memory 120 is a main memory, such as random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), etc. The system 100 includes a process 101 which is in the form of a system service, running in the processor 110 and communicating with the memory 120. The system service 101 is a first running process at a second stage boot loader. This system 100 can be used in a variety of implementations, such as personal computers (PCs), personal desk assistants (PDAs), notebook computers, cell phones and servers etc. Further, the controller 130 is configured to store the sensitive and secure data. The controller 130 has a trusted memory or a protected memory 140 that is configured to store the secure data. The system service 101 can access the trusted memory 140 only after it is authenticated by the controller 130.
[0037] Figure 2 illustrates a flowchart of the process of generating the hashes for trusted controller firmware, executable images, self by the system service at a second stage boot loader, according to an exemplary implementation of the present disclosure. This process comprises of generating the hashes by the system service 101. The system service 101 is configured to calculate the hashes of the running system modules such the trusted controller firmware, executable images, self, and the like. These generated hashes may be stored in the trusted memory 140 for the integrity checking of the subsequent booting of the system 100. At step 202, the system service is configured to send the generated hashes to the controller 202 to store in the trusted memory. If the authentication is failed then the further communication with the system service will be terminated. At step 203, the controller 130 is configured to receive the hashes from the system service and to validate that the received hashes are same as the ones that are sent by the system service 101. The controller 130 validates the received data from the system service 101. If the received hashes are not valid then the controller may reject the received hashes and terminates the communication. At step 204, if the received hashes are valid then the controller may encrypt the hashes received from the system service 101. At step 205, the controller 130 may store the encrypted hashes in the trusted memory.
[0038] Figure 3 illustrates a flowchart of the process of integrity checking at a second stage boot loader by the system service, according to an exemplary implementation of the present disclosure. This process comprises of verifying the integrity at the second stage boot loader, on-demand, and periodic interval by the user at runtime. At step 308, if the integrity is failed then the system service is configured to initiate to erase all the sensitive and important data stored in the trusted memory. At step 302, if the integrity is not failed then the system service is configured to send a request to the controller to retrieve the hashes from the trusted memory. At step 303, the controller is configured to authenticate the system service before exchanging the data by challenge request. At step 304, if the authentication is successful then the controller is configured to decrypt the hashes stored in the trusted memory and send to the system service. If the authentication is failed then the further communication with the System service will be terminated. At step 305, the system service is configured to receive the hashes from the controller and validate the received hashes are same as the ones that were sent by the controller. At step 306, the system service is configured to calculate the CRC of the received data and match with the CRC sent by the controller. If the received CRC is not matched with the CRC calculated by the system service, then the system service may reject the received hashes and terminate the communication. If the received CRC matches with the calculated CRC then the system service may perform integrity checking. At step 307, this integrity checking process comprises the comparing of the received hashes with the calculated hashes of the current running system. At step 308, if the hashes are matched then the system service allows user to use the system, otherwise the system service is configured to initiate to erase all the sensitive and important data stored in the trusted memory. At step 309, power-off the system to avoid further usage of the system.
[0039] Figure 4 illustrates a process of verifying the integrity of the system modules at periodic intervals by the processor, in accordance with an embodiment of the present invention. At step 401, this method includes calculating the plurality of hashes of the running system modules by the system service of the processor. The system modules includes such trusted controller firmware, executable images, and itself. At step 402, the method includes verifying the integrity of the running system by matching the hashes received from the trusted controller at second stage boot loader with the calculated hashes of the running system. At step 403, if the integrity is success then the system continues to operate and the system service performs the integrity checking periodically as per the periodicity configured by the user. At step 404, if the integrity is failed then the system service initiates to erase all the sensitive and important data stored in the trusted memory. At step 405, immediately after erasing all the sensitive data, the system service turns the power off of the running device or the system.
[0040] Figure 5 illustrates a flowchart of a method for integrity checking of an embedded hardware, in accordance with an embodiment of the present invention.
[0041] At step 502, generating a plurality of hashes for a plurality of system modules by a processor (110). In another embodiment, the processor (110) is configured to generate a plurality of hashes for a plurality of system modules.
[0042] At step 504, storing the generated hashes of the system modules by a trusted memory (140). In another embodiment, the trusted memory (140) is configured to store the generated hashes of the system modules for integrity checking at periodic intervals and on-demand by a user at runtime.
[0043] At step 506, analysing the generated hashes stored in the trusted memory (140) by the processor (110). In another embodiment, the processor (110) is configured to analyse the generated hashes stored in the trusted memory (140).
[0044] At step 508, calculating the plurality of hashes of the plurality of system modules by the processor (110). In another embodiment, the processor (110) is configured to calculate the plurality of hashes of the plurality of system modules.
[0045] At step 510, verifying the calculated hashes of the system modules with the generated hashes of the system modules stored in the trusted memory at periodic intervals by the processor (110). In another embodiment, the processor (110) is configured to verify the calculated hashes of the system modules with the generated hashes of the system modules stored in the trusted memory at periodic intervals and on-demand by the user at runtime.
[0046] In one of the exemplary implementation, a computer-implemented method for determining and generating the hashes of the executable images at the second stage boot loader for embedded hardware is provided. The method includes determining and generating the hashes of executable images by the system service storing the generated hashes of executable images in the trusted memory of the system for integrity checking at periodic intervals and on-demand by the user at runtime determining and generating the hash of trusted controller firmware for self-verification and verification by the system service storing the generated hash of trusted controller firmware in the trusted memory for further integrity verification.
[0047] In another exemplary implementation, a computer-implemented method for verifying the hashes of the executable images at the second stage boot loader for embedded hardware is provided. The method includes determining and reading the hashes of the executable images stored in the trusted memory. Thereafter, verifying the generated hashes of the running executable images with hashes of executable images stored in the trusted memory at periodic intervals and on-demand by the user at runtime. Further, the method includes determining and reading the controller hash stored in the trusted memory for self-verification and by the System service at the second stage boot loader. Furthermore, the method includes verifying the generated hash of controller with the hash stored in the trusted memory at periodic intervals and on-demand by the user at runtime.
[0048] At second stage boot loader, the system service generates the hashes of executable images and self and stores in the trusted memory. The system includes a memory for storing the hashes of trusted controller firmware, executable images, and self. The system also includes a processor for reading the hashes of trusted controller firmware, executable images and self and generating the hashes from the currently running executable images and the system service.
[0049] In another exemplary embodiment, the hashes of system service, trusted controller firmware and executable images are generated and stored in the trusted memory.
[0050] In another exemplary embodiment, the hashes of all modules may be encrypted by the controller before storing in the trusted memory.
[0051] In another exemplary embodiment, the system service may retrieve stored hashes from the trusted memory for verification of integrity of all modules. The trusted controller may decrypt the hashes stored in the trusted memory and send to the system service for integrity checking.
[0052] In another exemplary embodiment, the system service performs integrity checking for trusted controller firmware, executable images, and self by verifying calculated hashes of the running system modules against the hashes stored in trusted memory.
[0053] In another exemplary embodiment, the periodic interval integrity checking is performed by the system service for trusted controller firmware, executable images, and self. The periodicity at which integrity checking is performed can be configured by the user.
[0054] In another exemplary embodiment, the system service may perform the integrity checking automatically at the second stage boot loader, in case of integrity verification failure of any of the modules during integrity check, it may either stop further integrity checking of the other modules or erase all the sensitive and secure data stored in the trusted memory.
[0055] In another exemplary embodiment, the hashes stored in the trusted memory is not directly accessible to the system service. At the second stage boot loader, the stored hashes from the trusted memory can be accessed by the system service only after it is authenticated by the controller.
[0056] In another embodiment, an integrity verifiable system service can verify the integrity of the device, which runs at second stage boot loader. The system comprises the controller trusted memory to store the sensitive and secure data. The data stored in the trusted memory can be accessed by the system service only after it gets authenticated by the controller using the challenge request based authentication. The system service runs in the background and verifies the integrity of the trusted controller firmware and Executable images and itself. Further, the system service includes functionality that determines the hashes of the current running system modules at second stage boot loader. The system service stores the generated hashes of all the modules in trusted memory.
[0057] In another embodiment, the integrity checking on-demand and on periodic interval by the user at runtime is provided. The periodicity at which the integrity can be checked by the system service can be configured by the user. The verification function in the system service includes functionality that retrieves the hashes of the all the modules stored in the trusted memory. The system service verifies the integrity of the system modules by comparing the retrieved hashes from the trusted memory with calculated hashes of the running system modules.
[0058] The present disclosure ensures that currently running system is authentic. These exemplary embodiments are provided only for illustrative purposes and so that this disclosure will be thorough and complete. The disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Various omissions, substitutions, and changes in the form and details of the device and process will be readily apparent to persons skilled in the art. For example, for those skilled in the art will note from above that the process of integrity checking can be applied to Linux based system. The general principles defined herein may be applied to other embodiments and applications without departing from the scope of the disclosure.
[0059] The foregoing description of the invention has been set merely to illustrate the invention and is not intended to be limiting. Since modifications of the disclosed embodiments incorporating the spirit and substance of the invention may occur to person skilled in the art, the invention should be construed to include everything within the scope of the invention.
,CLAIMS:
1. A method for integrity checking of an embedded hardware, said method comprising:
generating, by a processor (110), a plurality of hashes for a plurality of system modules;
storing, by a trusted memory (140), the generated hashes of the system modules;
analysing, by the processor (110), the generated hashes stored in the trusted memory (140);
calculating, by the processor (110), the plurality of hashes of the plurality of system modules;
verifying, by the processor (110), the calculated hashes of the system modules with the generated hashes of the system modules stored in the trusted memory at periodic intervals;

2. The method as claimed in claim 1, wherein if the integrity verification of any of the plurality of system modules fails, said method further includes:
blocking, by the processor (110), the further integrity checking of the other modules; and
erasing, by the processor (110), all the sensitive and secure data stored in the trusted memory.

3. The method as claimed in claim 1, wherein if the integrity verification of any of the plurality of system modules is achieved, said method further includes:
permitting, by the processor (110), communication with the system modules by a user.

4. The method as claimed in claim 1, wherein the plurality of system modules includes trusted controller firmware, executable images, and itself.

5. The method as claimed in claim 1, said method further includes:
encrypting, by a controller (130), the generated hashes of the system modules before storing in the trusted memory (140).

6. The method as claimed in claim 1, said method further includes:
decrypting, by the controller (130), the hashes stored in the trusted memory (140); and
sending, by the controller (130), the decrypted hashes to the processor (110) for integrity checking.

7. The method as claimed in claim 1, said method further includes on-demand integrity checking of the system modules, wherein said on-demand integrity checking is performed by the user.

8. The method as claimed in claim 1, said method further includes:
retrieving, by the processor (110), the stored hashes from the trusted memory (140) for performing the integrity checking of the system modules.

9. The method as claimed in claim 1, said method further includes:
performing, by the processor (110), integrity checking at periodic intervals for the system modules, wherein the periodic intervals at which the integrity checking is performed is configured by the user.

10. The method as claimed in claim 1, said method further includes:
accessing, by the processor (110), the trusted memory (140) only after said trusted memory (140) is authenticated by the controller (130).

11. A system (100) for integrity checking of an embedded hardware at a second stage boot loader, said system comprising:
a processor (110), said processor is connected to a memory (120);
a process (101), wherein the process (101) is a system service which is configured to run in the processor (110) and to communicate with the memory (120);
a controller (130) configured to store a plurality of secure data;
a trusted memory (140) located in the controller (130), said trusted memory (140) is configured to store the plurality of secure data;
wherein the processor (110) is configured to generate a plurality of hashes for a plurality of system modules;
the trusted memory (140) is configured to store the generated hashes of the system modules for integrity checking at periodic intervals and on-demand by a user at runtime;
the processor (110) is configured to analyse the generated hashes stored in the trusted memory (140);
the processor (110) is configured to calculate the plurality of hashes of the plurality of system modules;
the processor (110) is configured to verify the calculated hashes of the system modules with the generated hashes of the system modules stored in the trusted memory at periodic intervals and on-demand by the user at runtime.