Trusted computing aims to build a trusted computing environment for information systems with the help of secure hardware TPM, which has been proved to be an effective way against network security threats. However, the TPM chips are not yet widely deployed in most computing devices so far, thus limiting the applied scope of trusted computing technology. To solve the problem of lacking trusted hardware in existing computing platform, an alternative security hardware USBKey is introduced in this paper to simulate the basic functions of TPM and a new reverse USBKey-based integrity verification model is proposed to implement the reverse integrity verification of the operating system boot process, which can achieve the effect of trusted boot of the operating system in end systems without TPMs. A Linux operating system booting method based on reverse integrity verification is designed and implemented in this paper, with which the integrity of data and executable files in the operating system are verified and protected during the trusted boot process phase by phase. It implements the trusted boot of operation system without TPM and supports remote attestation of the platform. Enhanced by our method, the flexibility of the trusted computing technology is greatly improved and it is possible for trusted computing to be applied in large-scale computing environment.
With the boom of Internet, the lack of a trustworthy infrastructure has been a barrel for the healthy development of modern computing systems. More and more threats are introduced due to the design flaws in software and hardware, the improper authorization and authentication for legal users, the abusing use of resources, and so forth. The key to solve these problems is to build a trustworthy computing environment, where the safety of end system is well designed and can be verified and trusted. Trusted computing technology proposed by the Trusted Computing Group (TCG) is one of the main practical efforts to achieve this goal. Trusted computing architecture is based on the trusted hardware, Trust Platform Module (TPM), and realizes transitive trust through the constant trust metric in the progress of system boot process to build a trusted computing environment.
Trusted platform module TPM and the related software are introduced in trusted computing platform technology to be as trusted root of the system, through the trust transfer process to ensure the credibility of computing platforms and applications and to improve the security of the terminal platform. However, in order to support a variety of security features in TCG specifications, a special trusted hardware TPM is required to be deployed in the mainboard, which has become a main barrier limiting the popularization of the trusted computing platform technology. TPM is the base of the trust chain and the trusted root throughout the trusted boot process, which records and transfers trusted states in end system. However, the TPM chips are not yet widely deployed in most computing devices so far, thus limiting the applied scope of trusted computing technology. It is almost impossible to implement an overall trusted network computing environment due to the hardware barrel.
To fix the problem of lacking trusted hardware in existing computing platform, an alternative security hardware, USBKey, is introduced in this paper to simulate the basic functions of TPM and a new reverse USBKey-based integrity verification model is proposed to implement the reverse integrity verification of the operating system boot process, which can achieve the effect of trusted boot of the operating system in end systems without TPMs.
We have designed and implemented a Linux trusted boot method based on reverse integrity verification, with which the integrity of data and executable files in the operating system are verified and protected during the trusted boot process phase by phase. It implements the trusted boot of operation system without TPM and supports remote attestation of the platform. Enhanced by our method, the flexibility of the trusted computing technology is greatly improved and makes it possible to be applied in large-scale computing environment.
The trusted hardware, TPM (Trusted Platform Module), plays a key role in trusted computing, working as the base of trusted computing architecture and the core to enhance the credibility of the general-purpose computing platforms and networks. At present, the core standard is TPM 2.0 [
Given the limitations in TPM’s architecture and cryptographic algorithms, new trusted computing architectures Trusted Cryptography Module (TCM) [
Recently, trusted mobile computing platforms and trusted cloud services are research focuses in both industry and academia. Studies relating to trusted mobile computing platform focused on TrustZone in smart devices, trusted identity management, privacy protection, and other aspects. Ekberg et al. propose ObC (On-board Credentials) system which allows third party to develop and deploy credentials in the device based on TrustZone and provides a TEE (Trusted Execution Environment) function for application developers [
Since not all platforms are equipped with TPM module, the traditional TPM leads to the loss of mobility and flexibility due to the binding of user’s identity with specific trusted platform. Accordingly, some scholars introduce some USBKey-based secure boot solutions based on the principles of separating platform and user certificate. To prevent the master boot record from easily being manipulated and infiltrated by bootkits, Müller et al. present Stark, which mutually authenticates the computer and the user in order to resist keylogging during boot and implements trust bootstrapping from a secure token (a USB flash drive) [
In summary, the more flexible and practical trusted boot technologies in operating system are being developed to be bound with new user application schemas and scenarios and to suit the development of mobile computing and cloud computing.
Trusted boot is one of the core functions of trusted computing platform. With the support of trusted hardware, a trusted running environment for services and applications is built with the verification of the integrity of the whole hardware and software during system boot process.
The following three key points must be guaranteed during the trusted boot process.
(1) The chain of trust must be established sequentially. Before the transference of control rights, the executable entity must be measured by trusted computing base. It can only be loaded and gain control rights after its integrity is verified, which fulfills the procedure of establishing chain of trust. (2) All the metrics and calls involved in the process of the establishment of the trust chain will eventually be completed by TPM. (3) During the establishment of chain of trust, all important secret data involved including keys, premeasurement data, and verification data must be stored and sealed inside TPM. TPM is responsible for ensuring the integrity and confidentiality of the secret data. Unlike removable storage devices or memory, there is no external call interface provided to access the secrete data in TPM, which ensures its confidentiality and credibility.
Taken the Linux trusted boot process based on TPM as an example, the trusted boot model in operating system is shown in Figure
Linux trusted boot model.
Trusted boot mainly includes two phases: the boot of hardware platform and the startup of operating system. The boot of hardware platform starts from the platform power on to the BIOS initialization and ends after the BIOS passes control rights to the boot loader. The reliability of hardware environment is measured and verified in this phase. The startup phase of the operating system begins with the loading of operating system loader from the main boot sector, and then the operating system kernel is loaded and ends till the running of the Init process. This stage is mainly responsible for checking the creditability of the system startup process and the operating system kernel. The trusted boot process of the startup phase of the operating system based on TPM is as follows.
Trusted BIOS loads boot loader stored in Boot sector and then sends it to TPM to be measured and verified. Once TPM has verified its integrity, the boot program is loaded to memory 0000:7C00h, and then the BIOS passes control rights to the CPU to run the Boot program to further load operating system.
TPM validates the operating system loader program, such as Grub in Linux. If the verification is successful, the Grub Stage 1 code in the master boot sector is loaded into memory and gains the trusted boot control to further load operating system kernel.
The Grub Stage 1 continues trusted boot process by first validating Grub Stage 1.5 code with TPM, if it is successful, loads, and runs the code of the Stage 1.5 phase. At the end of this stage, the file system is mounted.
The Grub Stage 2 code is verified by TPM and loaded by trusted Grub Stage 1.5. After successfully gaining control, it will verify the integrity of the configuration file “/boot/Grub/Grub.conf” in which the locations of the disk partitions, the kernel image, and virtual RAM disk file initrd are recorded.
The Grub Stage 2 code opens the configuration file, reads the operating system kernel image, and tries to verify the integrity of the operating system kernel image by TPM. If it is successful, the operating system kernel image is loaded and gains control.
Once the operating system kernel image is loaded, TPM will measure and verify the Init process. If the Init process is trusted, the kernel key data structures will be created and the kernel Init process will be loaded and take control.
Firstly, the Init process determines the list of the kernel modules needed to be loaded and the daemons needed to be created based on the system configuration. Then, it will measure and verify each kernel module and daemon with TPM module before they are loaded. Only the trusted kernel modules and daemons are run sequentially to guarantee that the initialized computing environment is trusted. At last, the Init process starts receiving users’ inputs, and a trusted computer is ready to be used.
At this point, the trusted operating system boot process is over. As we can see, the traditional trusted boot process based on TPM is in forward direction, which means all measurements and verifications are strictly consistent with the operating system boot process. The chain of trust is established in a strict sequence.
As shown in Figure
The reverse integrity verification model based on USBKey.
Working as a trusted root, TPM provides support for the storage of trusted measurement and trusted state (PCR) in the establishment of chain of trust during trusted boot. It is also the starting point and foundation of system trusted boot and trust measurement. Especially in TPCM framework, the trusted hardware is regarded as trusted base and is the first functional hardware after powering on the system, so as to provide guarantee to keep the whole system in trusted states.
Similar to the TPM, USBKey, as widely used security hardware, also has built-in security guarantee, built-in trusted measurement algorithms, and built-in secure storage space. But in order to implement trusted measurement as TPM module does, USBKey still needs to get rid of the following two limitations: (1) Hardware driver needs to be loaded before USBKey could be used, which makes it unable to activate trusted measurement from powering on the system as required in TPCM. (2) There are no PCRs in the USBKey built-in storage. New software data structures have to be designed to simulate PCRs in TPM, so as to record system’s trusted states and support trusted measurement during trusted boot.
To handle the first problem, we assume that a trusted prior measurement could be preceded by the kernel trusted measurement module while the system was in the initial trusted state. The trusted prior measurement generates foundation trust metrics for trusted measurement. To solve the second problem, a set of data structures are defined to simulate PCR registers in TPM which can be used to store the measurement values in the process of prior measurements and trusted boot. All measurement data are stored in safe storage area in USBKey.
The reverse integrity verification model based on USBKey is shown in Figure
In the reverse integrity verification model based on USBKey, the five key elements are
Operating system trusted boot method based on reverse integrity verification contains the following steps.
Following the system boot order, there are nine stages of data that are measured and verified in our method: The BIOS. The Grub Stage 1 data in the master boot sector. Grub Stage 1.5 data. Grub Stage 2 data. Grub configuration file. The kernel image file. The Init process data. The kernel modules to be loaded by the Init process based on the system configuration. The daemons to be loaded by the Init process based on the system configuration.
The nine stages can be divided into two parts: BIOS boot and operating system boot. The BIOS image needs to be measured and protected which includes codes for POST (Power-On Self-Test), system hardware initialization, and loading operating system boot loader. The operating system boot phase contains Grub Stage 1, Grub Stage 1.5, Grub Stage 2, the kernel modules and daemons loaded by the Init process.
In the method, the System Prior Measurement Program and the Reverse Integrity Verification Module are located in the operating system kernel, whose legitimacy and integrity are protected by USBKey signature. They can be loaded if and only if USBKey PIN verification and signature authentication are success. In this paper, SHA1 algorithm in USBKey is applied to perform trust measuring.
The different stages of system boot are premeasured by USBKey. The trust metric base is constructed by collecting system prior measurement data, which are used to support trust measurement with USBKey in the process of the trusted boot. The design of the prior measurement for the reverse integrity verification is shown in Figure
The design of the prior measurement for the reverse integrity verification.
In prior measurement phase, a regular system boot will be executed until starting to accept the user input. Then, the System Prior Measurement Program will be loaded and begin measuring each stage of system boot sequentially. The trust measurement values are calculated by USBKey and are stored into USBKey safe storage unit. The trust metric base is constructed after prior measurement phase. As shown in Figure Operating system boots up until receiving user input, that is, from powering on the system to the time the Init process is successfully running. Then, it inserts USBKey and verifies user’s PIN. If successful, To protect TCB in the method, USBKey precedes the summary and signature verification on the Reverse Integrity Verification Module Rev_Verify_Mod with user digital certificate inside. The results as Rev_Verify_Mod’s trust metrics are deposited in the safe storage unit in USBKey. The prior measurement process comes to an end.
After the completion of prior measurement, USBKey can reverse and verify the operating system booting process according to the stored prior metric values. To support USBKey-based verification, an operating system kernel module,
The trusted boot of operating system with reverse integrity verification.
After the prior measurement, the trusted boot is enabled. The system is powered on and operating system kernel is loaded. Once the USBKey is on, the Rev_Verify_Mod will be verified and loaded. Then, the Rev_Verify_Mod reads the trust metric base from the safe storage unit in USBKey. At last, the Rev_Verify_Mod sequentially reads the boot information of each phase and carries out the trust measurement and verification by comparing the current trust metrics with the premeasured values. If they are not equal, the system state is set as distrusted and the corresponding trusted boot failure handler is activated. If they are equal, the current system state is set as trusted and trusted boot continues to the next phase. When all system boot phases are completed successfully, the operating system is verified to be trusted and the trusted boot succeeds.
As shown in Figure Insert USBKey and system is powered on. The BIOS boots first, and then the operating system is loaded and boots until the Init process is successfully loaded and user interface is active. USBKey is enabled and the Init process requires user inputs PIN code to proceed to USBKey authentication. If USBKey authentication succeeds, it is ready to be used to proceed to trusted boot. First, the legitimacy and integrity of the Rev_Verify_Mod are verified by USBKey by comparing the calculated results with the prior measurement values. If they are identical, the authentication is successful. Then the Rev_Verify_Mod is loaded by operating system kernel, and the control is handled over to the Rev_Verify_Mod module. The Rev_Verify_Mod module reads the prior measurement values of each boot stage from trust metric base inside USBKey, which contains BIOS metric, Grub Stage 1 metric, Grub Stage 1.5 metric, Grub Stage 2 metric, the metric of the Grub configuration file, the operating system kernel image metric, Init process metric, kernel module metrics, and daemon metrics. The Rev_Verify_Mod module reads the BIOS information and measures its integrity with USBKey. By comparing the calculated results with the records of the BIOS metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the Grub Stage 1 data and measures its integrity with USBKey. By comparing the calculated results with the records of the Grub Stage 1 metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the Grub Stage 1.5 data and measures its integrity with USBKey. By comparing the calculated results with the records of the Grub Stage 1.5 metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the Grub Stage 2 data and measures its integrity with USBKey. By comparing the calculated results with the records of the Grub Stage 2 metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the Grub configuration file and measures its integrity with USBKey. By comparing the calculated result with the records of the Grub configuration file metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the operating system kernel image file and measures its integrity with USBKey. By comparing the calculated result with the records of the operating system kernel image file metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the Init process file and measures its integrity with USBKey. By comparing the calculated result with the records of the Init process file metric, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the data of the kernel modules to be loaded and measures its integrity with USBKey. By comparing the calculated results with the records of the kernel modules metrics, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. The Rev_Verify_Mod module reads the data of the daemons to be loaded and measures its integrity with USBKey. By comparing the calculated results with the records of the daemons metrics, the trustworthy state is judged. If they are equal, then trusted measurement succeeds and the current system is marked as in a trusted state; otherwise, the current system is marked as distrusted. Operating system boot is complete. During the process of the above reverse integrity verifications, the chain of trust is established by loading order. If any step encounters a verification failure, the system trusted boot fails and the system state is set to be distrusted and the corresponding trusted boot failure handler will be called which will normally suspend the system boot process or switch to the distrusted boot process. If all integrity measurements are successful in all steps, then the operating system is set to trusted status, and the trusted boot succeeds. The operating system trusted boot based on reverse integrity verification succeeds and system runs in a trusted computing environment.
USBKey is featured with low cost, safe, portable, convenient, and other characteristics. Compared with TPM, it can provide similar security functions with higher flexibility at the same time. They both have secure data storage space for sensitive data, such as trust metrics, digital certificates, and keys. Reading and writing operations on the safe storage space can only be achieved through the COS inside the hardware, which prevents the user from directly reading secret data. The user keys inside the safe hardware cannot be exported, which eliminates the possibility of the replication of user digital certificate or identity information. A variety of cryptographic algorithms are performed inside the safe hardware with the CPU inside. Operations such as encryption, decryption, and signature operations are performed within USBKey to ensure that the key will not appear in the computer memory, so as to prevent the fact that the user key may be intercepted by attackers. Therefore, by applying the USBKey and the reverse integrity verification method on operation system trusted boot, the system integrity can be guaranteed, and better flexibility and convenience are achieved.
In existing USBKey-based security enhancements methods, the USBKey is primarily used for user authentication, such as USBKey-based two-factor authentication, and data encryption and decryption. Our work in this paper extends the application field of USBKey. By constructing prior measurement libraries and reverse integrity verification modules, the USBKey in our method can simulate TPM and support key functions in trusted computing as trusted boot, trusted storage, and remote attestation.
The main advantages of the proposed method include the following: In the operating system trusted boot method based on the reverse integrity verification, the system is guaranteed by verifying the integrity of data and executable files in different booting stages. The verifications are not sensitive to loading sequence and are performed stage by stage to ensure that the system is in a trusted status. Compared with TPM-based trusted boot, USBKey based trusted boot is more compatible with application environment and is more flexibility and easier to be used in real computing systems. With the operating system trusted boot method based on the reverse integrity verification, the operating system trusted boot can be achieved on endpoints without TPMs, which greatly enhances the applicable scope of trusted computing technology. At the same time, the procedure for trusted boot is simplified, and trust measurements and verifications can be performed at any phase of system boot process through the reverse attestation method.
Compared with TPM-based trusted boot, the main disadvantage for our method is that the system is unprotected before the Rev_Verify_Mod module is loaded, which makes it possible to bypass the reversed verification procedure and boot a distrusted system. One solution is to enable USBKey and implement USBKey-based reversed verification in BIOS boot phase to achieve the lower level protection. Another option is to encrypt the file system with USBKey, which only can be decrypted after the system is verified to be trusted by the Rev_Verify_Mod module.
Remote attestation is one of the core functions in trusted computing. Users are able to authenticate the identity of the target platform and measure and verify the integrity of the trusted computing platform with remote attestation by using TPMs or TCMs.
Remote platform authentication is one of the key mechanisms in trusted computing, whose purpose is to prove the identity of a remote entity by exchanging and verifying a series of certificates with TPM. In 2004, Brickell and other scholars proposed TPM-based direct anonymous attestation (DAA) program [
TCG defines a binary remote attestation protocol to attest the integrity of the remote platform with trusted hardware TPMs/TCMs. But it is argued for the overexposure of the configuration information about the hardware and software in local trusted computing platform. To overcome the flaw in binary remote attestation, Chen and other scholars firstly proposed a property based attestation protocol, PBA protocol [
In China, the Trusted Connection Architecture (TCA) [
The basic authentication model in TCA.
Before establishing a trusted network connection, Access Requester (AR) and Access Controller (AC) must separately load PTS by calling the specific platform binding functions. Then the bidirectional user authentication protocol is performed, in which Policy Management (PM) acts as a Trusted Third Party (TTP). Platform A and Platform B collect integrity information with PTS protocol and then send the integrity information to PM. Finally the integrity of Platform A and Platform B is attested by PM.
The remote attestation of the platforms relies on TPM chips; therefore, it is hard for PTS to be widely used in practical network environment since most of the servers and the terminal nodes are not equipped with TPM/TCM chips. The USBKey-based reverse integrity verification method in this paper can simulate TPM to measure trusted boot process and verify the trust state of the node. The system trust metrics and simulated PCR values are stored inside safe hardware with same data structures, which can be used to support remote attestation with other trusted nodes with TPM. Therefore, it is possible to deploy USBKey-based reverse integrity verification mechanism on nodes without TPMs and build a hybrid trusted network environment supporting remote attestation on all nodes.
In a hybrid trusted network environment, bidirectional remote attestation protocol between TPM-based trusted nodes and USBKey-based trusted nodes is designed as follows.
As shown in Figure
Remote attestation in hybrid trusted network.
Aiming at the limitations in deploying and using TPMs in practical applications, we propose USBKey-based reverse integrity verification model which uses the widely used USBKey to establish chain of trust instead of TPM. The detailed design and implementation for this method are presented in Linux platform. The method supports the trusted boot of the Linux operating system. The PCR values are simulated to support the bidirectional remote attestation and trusted network connections between TPM-based trusted nodes and USBKey-based trusted nodes.
The proposed method greatly reduces the threshold for applying trusted computing technology. It has a wide prospective of applications and contributes a lot to the popularization of trusted computing technology in real enterprise environment.
The authors declare that they have no competing interests.
This work was supported by the National Natural Science Foundation of China (Grant nos. 61303191 and 61502510), the HGJ Major Project of China under Grant no. 2015ZX01040301, and Foundation of Science and Technology on Information Assurance Laboratory (no. KJ-14-107).