Field uf the Invention

[001] The present invention relates lu H system and method of establishing a trusted boot loader using a self-substantiated boot loader, in particular, the system and method protects the integrity of operating system boot loader layer by collecting, verifying and validating a plurality of platform evidences.

Background

[002] Many developments have been made in enhancing platform security via integrity measurement on a platform. In computers, the piali rm is an underlying computer system on which programs are run. The integrity of the computer system is verified by measuring a portion of the software and/or firmware running on the computer system.

[003] A conventional computer operating system usually segregates virtual memory into kernel space and user space. Kernel space is strictly reserved for running the kernel, kernel extensions and most device drivers. User space is the memory area where ail user mode applications work and this memory can be swapped out when necessary. Λ boot loader typically loads the main operating system lor the computer. [004] Existing boot loader has security features that only measures monolithic Linux kernel module. A monolithic kernel is an operati ng system architecture where the entire operating system is working in the kernel space. A monolithic kernel differs from other operating system architectures, such as microkernel architecture. In microkernel architecture., there are many kernel modules that need to be measured before being executed in the platform. [005] To enhance the existing security features scheme, there is a need for a system and method to provide platform evidences of the boot loader. This further provides a boot loader substantiation to ensure that the boot loader layer and the kernel modules are in trusted states.

Summary [006] In one aspect of the present invention, there is provided a system and method for establishing a trusted bout loader using a sel f-subslunliated boot loader in a computing platform. The method comprising the steps of loading and executing a Master Boot Record (MBR) and a Volume Boot Record; loading and executing a Real Time Operating System (RTOS); loading and executing a boot substantiation module; collecting platform evidences at a boot layer; verifying the collected platform evidences at least by comparing and verifying with the platform evidences stored in a core evidence storage module; establishing trusted communication with a server machine, wherein the trusted communication includes remote attestations and a plurality of encryption algorithms; reporting the platform evidences of a cl ient machine's platform to the server machine's platform; validating the platform evidences of the client machine ^' s plattonn with the platform evidences of the server machine's platform stored in an evidence storage module; updating the platform evidences of the client machine's platform by downloading a plurality of instructions from the server machine; enforcing the plurality of instructions from the server machine in the client machine's platform; and loading and executing trusted boot flies and kernel modules.

[007] In one embodiment, the loading and executing of the RTOS further comprises the steps of loading the MBR with a trusted Basic Input/Output System (RTOS) into a memory area of the computing platform; measuring, verifying and val idating the MBR; storing digests of the MBR as trusted MBR into a Platform Configuration Registers (PGR) extend; loading and executing the trusted MBR; measuring, verifying and validating of a tampcr-resislant device using the trusted MBR; continuing the booting of the computing platform without the boot substantiation module if verification and validation of the tampcr-rcsistant device fails, or measuring active partition table using the trusted MBR if verification and validation of the tamper- resistant device does not fail: storing the digests active partition table into the PGR extend; loading the VRR from the core evidence storage module using the trusted MBR; measuring, verifying and validating the VBR or disk partition; storing the digests of the VBR as trusted VBR in the PCR extend; loading and executing the trusted VBR using the trusted MBR: measuring, verifying and validating the RTOS using the trusted VBR; storing the digests of Ihe RTOS as Minimal RTOS in the PCR extend; and loading and executing the Minimal RTOS using the trusted VBR.

[008] In another embodiment, the loading and executing of the boot substantiation module further comprises the steps of obtaining a decryption key from a tampcr-rcsistant device using a Minimal RTOS; decrypting an encrypted data from the evidence storage module with the decryption key; measuring, verifying and validating the boot substantiation module using the Minimal RTOS; storing the digests of the boot substantiation module as trusted boot substantiation module in the PCR extend; loading and executing the trusted boot substantiation module into the memory area of the computing platform; and measuring Root of Trust for Measurement (R ^' l ^' M) from the core evidence storage module with the trusted boot substantiation module. [009] In one embodiment, the steps occur i n a sequential order.

[0010] In yet another embodiment, the trusted boot files includes trusted

Master Boot Record tiles and trusted Volume Boot Record files.

[0011] In another embodiment, the platform evidences includes proof integrity of the platform. [00 2] In another aspect of the present invention, the system comprises at least one client machine, wherein the client machine does a substantiation process, a verification process and an updating process on the client's machine's platform; a server machine, wherein the server machine verifies and updates the substantiation process on the client's machine ^' s platform; a core storage module, wherein the core storage module stores platform evidences in the client machine; an evidence storage module, wherein the evidence storage module stores platform evidences in the server maehine; a boot substantiation module , wherein the boot substantiation module resides in the client machine; a boot loader module, wherein the boot loader module resides in the server machine; a tamper-resistant device, wherein the tamper-resistant device resides in the server machine and the client machine; and a virtual Trusted Platform Module (vTPM) server machine, wherein the vTPM comprises a plurality of vTPM instances and the tamper-resistant device; wherein the boot substantiation module substantiates, verifies, validates and updates platform evidences; executes a server machine's instruction: <tnd wherein a Minimal Real Time Operating System (RTOS) loads and executes trusted boot files and kernel modules.

Brief Description of the Drawings [0013] This invention will be described by way of non-l imiting embodiments of the present invention, with reference to the accompanyi g drawings, in which:

[0014] FIG. 1Λ illustrates an overall architecture of a computer platform using a self substantiated boot loader as one embodiment in the present invention;

[0015] FTG. I B illustrates the various components in the multiple layers of the client machine and the server machine;

[0016] FIG. 2 is a process-flow diagram of illustrating a method of the self substantiated boot loader as another embodiment of the present invention;

[0017] FIG. 3Λ illustrates a process-flow diagram of the Master Boot Record

(MBR) flow; [0018] FIG. 3B illustrates a process-flow diagram of the Volume Boot Record

(VBR) flow;

[0019] FTG. 3C illustrates a process-flow diagram of the Real Time Operating

System (RTOS) flow;

[0020] FIG. 3D illustrates a process-flow diagram of an Operating System Kernel (OSF RNL) flow; and [0021J l^lO. 3E illustrates an overall block diagram of a trusted boot loader using the self-substantiated boul loader.

Detailed Description

[0022] The following descriptions of a number of specific and alternative embodiments arc provided to understand the inventive features of the present invention. It shall be apparent to one skilled in the art, however that this invention may be practiced witliout such specific details. Some of the details may not be described in length so as to not obscure the invention. For ease of reference, common reference numerals will be used throughout the figures when referring to same or similar features common to the figures.

[0023] FT . 1 A illustrates an overall architecture of a computer platform using a self-substantiated boot loader as one embodiment in the present invention. The computer platform comprises at least one client machine 101, a server machine 102 and a virtual Trusted Platform Module (vTPM) server machine 103. The client machine 101 docs a substantiation process, a verification process and an updati ng process on the client machine's 101 platform. The server machine 102 verifies and updates the substantiation process on the client machine's 101 platform.

[0024] The client machine 101 comprises a software layer and a hardware layer.

The software layer includes a user space layer, a kernel space layer and a b ol loader layer. The hardware layer includes a physical and virtual machine layer. The user space layer is the memory area where all the applications work. The kernel space layer is strictly reserved for running kernel modules (eg. Monotlithic kernels or microkernels) and eLu. Kernel modules in Lhe main component of most operaling systems. The boot loader layer i ncludes a boot substantiation module 104. The physical or virlual machine layer includes hardware, firmware, a core evidence storage module 105 and a iamper- rcsislanl device 106. The core evidence storage module 1.05 stores a plurality of platform evidences. The platform evidences include core platform evidences, client platform evidences. Volume Boot Record (VBR) and etc.

[0025] Similar to the client machine 101, the server machine 102 comprises a software layer and a hardware layer. However, the boot loader layer in the server machine 102 includes a boot loader module 107 and the physical or virtual machine layer includes hardware, firmware, an evidence storage module 108 and the tamper- resistant device 106. The evidence storage module 108 stores a copy of the platform evidences from the core evidence storage module 105 and a plurality of server machine's 102 instructions. Further, the user space layer of the server machine 102 includes an application substantiation module 109. The application substantiation module 109 comprises an attestation server and a validation substantiation s}'stem.

[0026] The boot substantiation module 1 4 establishes platform substantiation at the user space layer and the kernel space layer of the server machine 102. This will protect the integrity of the user space layer and the kernel space layer by collecting, verifying and validating the platform evidences without disturbing or modifying existing operating system. Further, it performs forensic activities including collecting and measuring the integrity of the platform evidences in the user space layer and the kernel space layer to ensure that it is running in trusted states via a remote validation with the server machine 102. [0027] The boot substantiation module 1.04 and the boot loader module 107 reside in the client machine 101 and the server machine 102 respectively. Both the boot substantiation module 104 and the boot loader module 107 do (he substantiation process on both the client machine 101 and the server machine 102. Similarly, the cove evidence storage 105 and the evidence storage module 108 residing in the client machine 101 and the server machine 102 respectively also do the substantiation process on both the client machine 101 and the server machine 102.

[0028] The v ITM server machine 103 comprises a plurality of vTPM instances and the tamper-resistant device 106. The vTlWl instances associates with a virtual machine. The vTPM instances are known to those skilled in the art, and therefore, no further illustration is provided herewith.

[0029] In one embodiment of the present invention, the boot substantiation moduie 104 operab!y communicates with the vTPM server machine 103 to capture all the platform evidences. The boot substantiation module 104 then performs measurement on the integrity of the platform evidences and updates the platform evidences and platform configurations to the server machine 102 for validation. Thereafter, the boot substantiation module 104 will make a security decision. The following FIGs. 2-3E discusses a method of the boot substantiation module 104 in greater detail. [0030] In another embodiment of the present invention, for a client-server based solution, a remote attestation will be used to verify and validate the platform evidences, in another embodiment in the present invention, the tamper-resistant device 106 includes a Trusted Platform Module (TPM) or a virtual TPM. The lamper-resisiariL device stores platform integrity measurements and secrets of the computing platform 100.

[0031] FIG. I B illustrates the various components in the multiple layers of the client machine 101 and the server machine 102. The user space layer, the kernel layer, the boot loader layer and the physical or virtual machine layer communicates through a trusted interlace. The tmsted interface is a trusted inter-process communication (IPC) _. , which allows the multiple layers to communicate in a secure and trusted environment.

[0032] FIG. 2 is a process-flow diagram of illustrating a method 200 of the self-substantiation boot loader as another embodiment of the present invention. Firstly, a Master Boot Record (MBR) and a Volume Boot Record (VBR) loads and run a Real Time Operating System (R ^' i ^' OS) and the boot substantiation module 104 in step 201. The MBR and the VBR are stored in a physical storage device such as a hard disk (HE ⁾ ) and etc. The MBR may be used to hold a partition table that describes the partitions of the physical storage device. The VBR is a disk partition table of the active partition table loaded from the MBR.

[0033] In step 202, the boot substantiation module 104 collects all the platform evidences at the boot layer of the client machine 101 and the server machine 102. Examples of platform evidences include proof integrity of the platform and hardware properties such as manufacture date, serial number, version, test functionality of the client machine 101 etc. In step 203, the boot substantiation module 104 verities the collected platform evidences with the core evidence storage module 105 in the client machine 101. [0034.} in step 204, if booting up needs a validation in order to boot up the computing platform, the boot substantiation module 104 sends the collected platform evidence to the server inachinc 102 for a validation process. The boot substantiation module 104 establishes communication with the server machine 102 through a trusted communication, and reports the platform evidences from the client machine's 101 platform to the server machine's 102 platform. The trusted communication includes remote attestations and a plurality of encryption algorithms. The platform evidences of the client machine's 101 platform arc validated vith the platform evidences stored in the evidence storage module 108. Thereafter, the platform evidences arc updated in the client machine's 101 platform by downloading a plurality of instructions from the server machine 1 2.

[0035] In step 20S, the boot substantiation module 104 executes the server machine's 102 instruction for a next stage booting in the client machine's 101 platform. In step 206, a Minimal RTOS loads and executes a trusted boot files arid kernel modules. The steps 201-206 occur sequentially.

[0036] l«'lGs. 3A-3D provides a further explanation on the method 200 of the self-substantiation boot loader in sequential order.

[0037] FIG. 3 A illustrates a process-flow diagram of the MBR flow. The method 200 first begins with a taisted Basic Inpul/Oulput System (BIOS) loading MBR into the memory area in step 301. In step 302, the trusted BIOS measures, verifies and validates the MDR. The digests of the MBR are stored as trusted MBR in a Platform Configuration Registers (PGR) extend in step 303. In step 304, the misled BIOS loads and executes the trusted MBR. The trusted MBR then docs the measuring, verifying and validating the tamper-resistant device 106 in step 305. If the tamper-resistant device 106 docs not exist, the computing platform continues to boot without the boot substantiation module 104 in step 306 and the MBR flow ends. If the tanipcr-rcsistant device 106 does exist, the trusted MBR. measures an active partition table in step 307 and stores the digests of the active partition table as the VBR into the PCR extend in step 308. In step 309, the trusted MBR loads the VBR from the core evidence storage module 105. Thereafter, the process- low diagram of the method 200 will be further illustrated in FIG. 3B. [0038J PIG. 3B illustrates a process-flow diagram of the VBR flow. After step

309 in FTG. 3Λ, the trusted MBR measures, verifies and validates the VBR or disk parLiUon in step 310. In sLep 311, the digests of the VBR arc stored as trusted VBR in the PCR extend. After measuring the VBR, the trusted MBR loads and executes the trusted VBR in step 312. The trusted VBR then does the measuring, verifying and validating of the RTOS in step 313. In step 314, the digests of the RTOS is stored as Minimal RTOS in the PCR extend. In step 315, the trusted VBR loads the Minimal RTOS from the core evidence storage module .105. In step 316, the trusted VBR calls the Minimal RTOS lu obtain a decryption key from the (amper-resistant device 106 in step 317. The process-flow diagram of the method 200 will be described in further details in FIG. 3C.

[0039] FIG. 3C illustrates a process-flow diagram of the RTOS flow. After step

317 in FIG. 3JB. the Minimal RTOS uses the decryption key to decrypt an encrypted data from the tamper-resistant device 106 in step 318. In step 319, the Minimal RTOS measures, verities and validates the boot substantiation module 104 from the core evidence storage module 105. If the core evidence storage module 1 5 lias external core evidence, it downloads the external core evidences from the server machine 102. The external core evidences arc then measured, verified, and validated. In step 320, the digests of the boot substantiation module 104 is stored as trusted boot substantiation module in the PCR extend. After measuring the boot substantiation module 104, the Minimal RTOS loads and executes the trusted boot substantiation module into the memory area of the computing platform in step 321. In step 322, the Minimal RTOS calls (pass the booting control) for the trusted boot substantiation module. In step 323, the trusted boot substantiation module measures Root of Trust for Measurement (RTM) from the cere evidence storage module 105. The digests of the R M are stored in the PCR extend in step 324. In step 325, the trusted boot substantiation module loads and calls for the RTM. Thereafter in step 326, a local trusted configuration is initialized. In step 327. the local trusted configuration is synchronized with the server machine 102. The process-flow diagram of tlic method 200 w ll be described in further details in FIG. 3D,

[0040] FTG. 3D illustrates a process-flow diagram of an Operating System

Kernel (OSKRNf .) flow. After step 327 in FrG. 3C, the server machine 102 compares the latest client's platform evidences from the client machine 101 with the platform evidences stored in the server machine's evidence storage module 108 in step 328 before validating with the server machine 102. If the platform evidences are not valid, the client machine 101 is informed thai the client machine 101 is not trusted in step 329. In step 330. the self-substantiation boot loader ends, if the platform evidences are valid, the client machine 101 is informed that the client machine is trusted in siep 331. The RTOS then loads the operating system boot files from the decrypted volume (the OSKRNL and boot drivers) in step 332. In step 333. the RTOS validates the signatures of the operating system boot files. In step 334, the RTOS loads and calls the OSKRNL to boot the operating system. In step 335, the process-flow diagram of the method 200 ends.

[0041] FIG. 3E illustrates an overall block diagram of a trusted boot loader using the self-substantiated boot loader. The trusted boot loader focuses on how to collect platform evidences. The block diagram shows that the trusted boot loader can be divided into four sections (MBR, VBR, Minimal R OS and OSKRNL).

[0042] Firstly, the MBR have been modified to measure the VBR and the values arc stored accordingly in the PCR extend. The VBR is used to load the Minimal RTOS. The Minimal RTOS is a small 16-bit OS used to validate the MBR and the VBR. It is also used to dectypt the Hard Disk partition and checks the integrity of the platform evidences.

[0043] Thereafter, the trusted boot files and the OSKRNL are loaded by the

Minimal RTOS. in one embodiment of the present invention, the OSKRNL that is loaded and executed are kernel modules. In another embodiment of the present invcntion _; the trusted hoot files includes the trusted MBR files and the trusted VBR files. ί0044] The present invention provides a system and method for establishing a trusted boot loader using a self-substantiated boot loader in a computing platform. It is a Minimal Real- Time Operating System ( TOS) that loads and executes a trusted boot files a il kernel moduLes. The system and method capture platform evidences from a cl ient machine and a server machine, performs measurement on the integrity of the platfoi'm evidences to ensure that it is limning on trusted states, and updates the platform evidences and platform configurations to the server machine for validation. The platform evidences ure updated in the client machine by downloading a plurality of instructions from ihe server machine. Any changes in the platform may show that the platform is compromise by unknown entities. The system runs as pari of the boot loader modules to provide trusted environment to the operating system. The system and method is operable with or without TPM chip.

[00451 The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. While specific embodiments have been described and illustrated it is understood that many charges, modifications, variations and combinations (hereof could be made to the present invention without departing from the scope of the present invention. The above examples, embodiments, instructions semantics, and drawings should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims: