Seal-based secure boot scheme for trusted computing platform

The Journal of China Universities of Posts and Telecommunications December 2010, 17(Suppl. 2): 16–21 www.sciencedirect.com/science/journal/10058885

http://www.jcupt.com

Seal-based secure boot scheme for trusted computing platform SONG Cheng1,2 ( ), PENG Wei-ping1,2, XIN Yang1,2, LUO Shou-shan1,2, ZHU Hong-liang1,2,3 1. Information Security Center, Beijing University of Posts and Telecommunications, Beijing 100876, China 2. Key Laboratory of Network and Information Attack and Defence Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China 3. Beijing Safe-Code Technology Co.,Ltd, Beijing 100876, China

Abstract

Secure boot is one important way to ensure the security of system for the terminal computing platform. The existing solutions for platform secure boot are based on verification by matching the reference measurements with the runtime measurements. These solutions are complex and inefficient. Based on the existing secure boot scheme, a secure boot model based on trusted personal computer (PC) is designed. Through the use of the existing trusted computing technology, a seal-based secure boot scheme for trusted computing platform is proposed in this paper. In this scheme, it is not necessary to generate the certificates on components of the reference measurements; it is also not necessary for verification proxy to verify the integrity of the runtime measurements. At the same time, the security of platform system is effectively guaranteed during booting. Keywords trusted computing, trusted platform module, seal, secure boot

1

Introduction1

The trusted computing platform alliance (TCPA) [1–2] is an industry alliance formed in October 1999 that focuses on developing and standardizing Trusted Platform technology. This technology is promoted by major companies such as HP, IBM, Intel, and Microsoft. In spring 2003, the TCPA was renamed as the trusted computing group (TCG) [3]. A core component of the specification issued by the TCG is the trusted platform module (TPM) [4]. TPM is viewed as functionally equivalent to a high-end smart card. Usually TPM is a small chip soldered to the motherboard [5]. TPM can be used to significantly enhance system security. Computing Platform embedded TPM is defined trusted computing platform (TCP) in TCG. TCP is an entity that always behaves in the expected manner for the intended purpose. In other words, TCP is trusted by both the local user and the remote verifier trust. Trusted Computing Platform during booting will measure the state of the system. When the platform is bootstrapped, the

Received date: 15-11-2010 Corresponding author: SONG Cheng, E-mail: [email protected] DOI: 10.1016/S1005-8885(09)60589-6

non-updatable portion of BIOS (BIOS Boot Block, or BBB) measures the integrity of the BIOS image and stores the value into one of the PCRs [4]. The BIOS then measures the OS loader and stores the value into one of the PCRs before execution is transferred to the OS loader. The OS Loader then measures the OS and stores the value into one of the PCRs before execution is transferred to the OS. Finally, the OS measures application component and stores the value into one of the PCRs. In this way, a chain of trust is established from the BBB onwards to ensure the integrity of platform state. The BBB usually is defined as core root of trusted measurement (CRTM). During the process, the state of system components is only measured, but don’t verify the integrity of measurement value. The boot process is defined as trusted boot. However, if the boot components (such as BIOS and OS) were infected by the virus or malicious code, they can not be automatically found by the local platform. Secure boot is based on trusted boot. Add a verification operation between measuring component and transferring execution. If the runtime measurement value matches the expected reference value, continues the boot process; otherwise, aborts the boot. Therefore, secure boot can be achieved more fine-grained security control for computing

Supplement 2

SONG Cheng, et al. / Seal-based secure boot scheme for trusted computing platform

platform. It is very valuable for smart devices requiring a higher security. Otherwise, these existing schemes are complex and inefficient. To make up for the limitations of the existing solutions, a seal-based secure boot scheme for trusted computing platform is proposed. The rest of this paper is organized as follows: In Sect. 2 we introduce the related work. Sect. 3 proposes a secure boot model based on PC. Sect. 4 describes the seal-based secure boot scheme for trusted computing platform which we present. Finally, we discuss the performance of the proposed scheme and present the conclusions in Sect. 5.

17

chain can be expressed as: I 0 True,

I i 1

­ I i š Vi ( Li 1 ); i 0,3,4 ° n ° Vi ( Lli 1 ); i 1 ® Ii š ¦ l 1 ° °¯ I i š Vi 1 ( Li 1 ); i 2

Where I i denotes the system integrity at level i. Before control is handed over to the subsequent level i  1 , an integrity verification function Vi checks the integrity of the code Li 1 being invoked. The n denotes the number of

expansion ROMs in the system.

2

Relate works

In 1991, Yee [6] first presents the concept of a secure boot process in 1991. In Yee’s model, a cryptographic coprocessor is firstly to gain control of the system. Unfortunately, this is impossible without a complete revision of most platform systems— even if the coprocessor is tightly coupled. In 1994, Yee extends his discussion of a secure boot in his thesis [7], but he continues to agree that the coprocessor should control the boot process that verifies each component prior to its use. In Lampson’s model [8], the entire boot ROM is trusted, and he does not address the verification of expansion cards/ROMs. In 1993, The Birlix [9] Security Architecture proposes a model designed by Michael Gross that is similar to Lampson’s. The Birlix model also suffers from the same problems. In both solutions, the boot ROM is responsible for generating a key pair for use in host based authentication once the OS is running. In 1994, Clark [10] presents a secure boot process for DOS that stores all of the OS bootstrap code on a PCMCIA card. However, he does not address the verification of any firmware. Clark’s model permits mutual cryptographic authentication between the user and the host. However, the use of a PCMCIA card creates several configuration management problems. Since today many users have multiple operating systems on their PC, a user needs a separate PCMCIA card for each operating system they wish to use. In 1997, W. Arbaugh, D. Farber and J. Smith discussed the secure boot process in Ref. [11] and proposed a secure boot architecture (‘AEGIS’) for PC-style computers that assured a system’s integrity by creating a chain of integrity checks in the bootstrap process. In AEGIS, the system boot process is divided into five levels of abstract (see Fig. 1), which correspond to phases of the bootstrap operation. The integrity

Fig. 1 AEGIS boot process

In Ref. [11], the AEGIS architecture considers the more complex boot sequence based on typical PC platforms. Most complexity of the PC boot sequence is caused by the various hooks inside the PC BIOS. As a result, the formulation of boot integrity checks shown above becomes much more complex. The sAEGIS [12] is an extension to AEGIS that implements secure boot. To reduce the needed trust in the system administrator, a smart card is used to store certificates and hashes of trusted systems. Both AEGIS and sAEGIS projects are based on a modified BIOS, which prevent a wider usage of them. In 2008, Kurt Dietrich and Johannes Winter [13] propose a software image verification concept, which is based on the reference-integrity-metric (RIM) certificates specified by the TCG and allows an easy verification of the loaded software images as well as easy management of RIM certificates to support the secure boot process. However, it is necessary for each boot component to generate the RIM certificate. If the

18

The Journal of China Universities of Posts and Telecommunications

component is updatedˈthe certificate is also updated and re-embedded into the corresponding to component.

2010

The advantages and disadvantages of these secure boot process are shown in Table 1.

Table 1 Advantages and disadvantages of the existing these secure boot process Secure boot processes In Ref. [6] In Refs. [8–9] In Ref. [10] In Refs. [11–12] In Ref. [13]

Advantage First present the concept of the secure boot The entire boot ROM is trusted Mutual authentication between the user and the host Create a chain of integrity checks Easy verification

3 Secure boot model based trusted PC Secure boot is that the system is halted when boot process doesn’t achieve the expectation. Secure boot will be finished by measurement proxy cooperating with verification proxy. In early trusted computing platform, Expectant state values (reference measurement values) are stored in non-volatile random access memory (NVRAM) inside TPM. Firstly, the platform owner places the reference measurement value of every boot component in NVRAM. Every level during secure boot process, the measure proxy measures the subsequent boot component, then the verification proxy compares the measurement result with expectant value in NVRAM. If match, boot continues; else, boot halts. Secure boot includes two important aspects: one is creating reference measurement value; the other is integrity measurement and verification. The reference measurement value provides criterion for deciding whether a platform is secure. The use of reference measurement is not limited to local verification during secure boot process. It is necessary for remote verification during the platform integrity reporting. Generally, the reference measurement value is generated by manufacture of the

Fig. 2

Disadvantage Complete revision of most platform systems Can’t address the verification of the expansion cards/ROMs Can’t address the verification of any firmware Based on a modified BIOS Flexibility is poor

component. When the manufacture doesn’t provide the reference measurement the user of platform need create it. The reference measurement that the manufacture generates is usually a certificate which can be obtained from internet or storage medium. A goal of integrity measurement and verification interoperability is to establish a match between measurement processes and verification. Integrity measurement is a hash operation on data which describe properties and characteristics of the measured component. Verification is to compare the result of the integrity with the reference measurement. Then, procedure of integrity confirmation will be achieved by comparing end value and standard value. The related information of the runtime measurement is important, because its structure will determine the effectiveness and efficiency of measurement process and verification process. It is generally recommended that the structure of the runtime measurement is the same as the structure of the reference measurement. We design a security boot model based on trusted PC (Fig. 2). In the model, Tpm_extend operation after measure is omitted. The detailed process of secure boot is as follows:

Secure boot model based on trusted PC

Supplement 2

SONG Cheng, et al. / Seal-based secure boot scheme for trusted computing platform

Step 1 The PC is powered on and reset. The PCRs are reset to their dafaut values, then the platform boots the CRTM. Step 2 After CRTM boots, it measures BIOS and saves the measurement result into some PCR via tpm_extend command. Then the verification proxy matches the measure result with the corresponding reference values in the RIM inside TPM. If match, boot BIOS and hand over execution control to it; else, halt boot. Step 3 After BIOS boots, first, it measures OS Loader and saves the measurement result into some PCR via tpm_extend command. Then the verification proxy verifies the result with the corresponding reference values in the RIM. If match, boot OS Loader and hand over execution control to it; else, halt boot. Step 4 After OS Loader boots, it measures OS and saves the measurement result into some PCR via tpm_extend command. Then the verification proxy verifies the result with the corresponding reference values in the RIM. If match, boot OS , hand over execution control to it and boot success; else, halt boot.

4 4.1

Note that the input PCR values are generally not the values of the current state of Platform, but the PCR values under a special state. Unseal can be understood as an inverse operation of seal (shown in Fig. 4). However, there is some restrictions during unseal process. When user wants to obtain the secret data which is sealed, the unseal command takes the sealed data and the Auth Material as input, then TPM decrypts the sealed data. Finally, the TPM compares the PCR values in sealed data against the current values of those corresponding PCRs. If they match, the TPM outputs the resulting data. If any of the checks fail, the TPM simply returns an error.

TPM_seal based security boot scheme Seal and unseal

Fig. 3

Fig. 4

4.2

The so-called ‘seal’ can be understood as a strengthening of the encryption technology. At an abstract level, the TPM presents a simple interface for binding data to the current PCRs via the TPM operations. The seal command takes a set of PCR values, the Auth Material that authorizes to use some storage key and the data that will be encrypted as input, and encrypts the data and selected PCR values using corresponding to storage key. It outputs the resulting ciphertext sealed data into local storage (shown in Fig. 3).

Seal operation

19

Unseal operation

Secure boot scheme

In Sect. 2, we analyze the existing secure boot process. All the schemes are based on verification by matching the reference measurements with the runtime measurements. As a result, the reference measurement for each boot component must be created beforehand. The reference measurement may be certificate. If not, it must be stored in a secure storage medium which can retrieve when requirement. In this section, we propose a seal-based secure boot scheme for trusted computing platform. This scheme mainly uses the existing TPM seal technology to achieve secure boot. The secure boot process of the scheme is shown in Fig. 5. Detailed steps are as follows: Step 1 Platform powers on. Step 2 CRTM boots, then measures itself and extends the measurement values into corresponding PCRs. Step 3 CRTM calls the TPM_unseal command. Step 4 TPM compares the PCR values in sealed data against the current state values of these corresponding PCRs. If match, execute the next step; else, halt boot.

20

The Journal of China Universities of Posts and Telecommunications

2010

Step 5 The component that has the rights of execution control measures the subsequent boot component, extending the measurement values into corresponding PCRs booting the component. Step 6 The component that has the rights of execution control hands over the execution control to the booting component. Step 7 The platform judges whether the component that has the rights of execution control is last boot component. If last, execute the next step; else, execute Step 3. Step 8 Last boot component calls the TPM_unseal command. Step 9 TPM compares the PCR values in sealed data against the current state values of these corresponding PCRs. If match, secure boot success; else, halt boot.

5 Discussion and conclusions 5.1

Discussion

Compared with the existing secure boot process, the proposed scheme is convenient and effective, secure, and feasible (Table 2). Fig. 5 TPM_seal-based secure boot process Table 2 The capability compare of secure boot process Secure boot process

Description

In Ref. [6]

A cryptographic coprocessor is required to control the system firstly , which results to a complete revision

In Refs. [8–9]

The entire boot ROM is trusted. The expansion cards/ROMs can’t be measured and verified. the boot ROM is required for generating a key pair

In Ref. [10]

All of the OS bootstrap code is stored in a PCMCIA card. The firmware can’t be verified. There are some configuration management problems,

In Refs. [11–12]

The system boot process is divided into five levels of abstract and builds a chain of integrity checks in the bootstrap process. The integrity check is very complex. The BIOS is required modification.

In Ref. [12]

It is an extension to AEGIS. A smart card is required to store certificates and hashes of trusted systems. The BIOS is required modification.

In Ref. [13]

It is based on the RIM certificates. Update of the components leads to update of the certificates and re-embedded.

This scheme

The reference measurement is not required. The system is only required slight modification. The verification is effective and not requiring the verification proxy.

Firstly, it is not necessary for any component to generate the reference measurement, because the existing TCG seal technology can seal the secure state of every level into the platform; it is also not necessary for verification proxy to verify the runtime measurement, because verification can automatically be implemented by calling TPM_unseal command. Secondly, the sealed state values are secure, because they are asymmetrically encrypted by TPM storage key.

Lastly, it is not necessary to assume that the CRTM is secure, because the integrity of CRTM is immediately verified after the CRTM booting. Slight modification to the system of trusted platform can support our scheme. 5.2

Conclusions

In this paper, we analyze the existing secure boot model and design a secure boot model based on trusted PC. Then a TPM_seal-based secure boot scheme is proposed. In the

Supplement 2

SONG Cheng, et al. / Seal-based secure boot scheme for trusted computing platform

proposed scheme, it is not necessary to generate the reference measurements for any boot component; it is also not necessary for verification proxy to verify the integrity of the runtime measurements. It is also secure and feasible. Acknowledgements This work was supported by the Hi-Tech Research and Development Program of China (2009AA01Z439), the National Natural Science Foundation of China (60821001, 60973146), the National Basic Research Program of China (973 Program) (2007CB310704).

References 1. Trusted Computing Platform Alliance. TCPA Design Philosophies and Concepts Version1.0, 2001 2. Trusted computing platform alliance (TCPA). TCPA Main Specification Version 1.1, 2002 3. TCG: TCG Specification Architecture Overview. TCG Specification Version 14, 2007

21

4. TCG: TPM Main Part 1: Design Principles. TCG Specification Version 1.2 Revision103, 2007 5. TCG. Design, Implementation, and Usage Principles Version 2.0, 2005 6. Tygar J D, Yee B. Dyad: A system for using physically secure coprocessor. Techmcal Report CMU-CS-91-140R, Carnegie Mellon University, 1991 7. Yee B. Using Secure Coprocessor. Pennsylvania, USA: Carnegie Mellon University, 1994 8. Larnpson B, Abadi M, Burrows M. Authentication in distributeds ystems: Theory and practice. ACM Transactions on Computer Systems, Vol 10, 1992: 265–310 9. Hartig H, Kowalski O, Kuhnhauser W. The Birlix security architecture. Journal of Complcrer security, 1993, 2(1): 5–21 10. Clark P C. BITS: A Smartcard Protected Operating System. Washington, DC, USA: George Washington University, 1994 11. Arbaugh W A, Farber D J, Smith J M. A secure and reliable bootstrap architecture. In SP’97: Proceedings of the 1997 IEEE Symposium on Security and Privacy, Washington, DC, USA: 1997 12. Naomaru Itoi, William A, Arbaugh, et al. Personal secure booting. In Proceedings of the 6th Australasian Conference on Information Security and Privacy. Springer-Verlag, 2001: 130–144 13. Dietrich Kurt, Winter Johannes. Secure Boot Revisited. In Proceedings of the 9th International Conference for Young Computer Scientists. IEEE Computer Society, 2008: 2360–2365