In the past few years, increasing volumes of computer

Transcription

1 Enhancing PC Security with a A boot system that uses a can help ensure the integrity of fairly static PC components. Moreover, the associated two-factor authentication makes a mobile computer s theft less likely because a thief can t use it. PENG SHUANGHE AND HAN ZHEN Beijing Jiaotong University In the past few years, increasing volumes of computer viruses and corresponding attacks have emerged, and they re likely to get worse. Cryptography and other technical security measures such as firewalls and intrusion detection systems (IDS) can solve a variety of security-related problems, but they work properly only if the underlying computing platform specifically, the operating system is secure. Unfortunately, most computing platforms suffer from various security problems owing to their architectural weaknesses and complexity. To address these issues, the computing industry has invested in trusted computing, a new generation of computing platforms based on improved hardware and software architectures. In particular, two well-known initiatives from the Trusted Computing Group (TCG; an alliance of leading IT enterprises, and Microsoft have emerged. No technical specifications for Microsoft s Next Generation Secure Computing Base (NGSCB; com/resources/ngscb/default.mspx) are available yet, but the TCG has published hardware specifications for its Trusted Platform Module (TPM; computinggroup.org/faq/tpmfaq/). Essentially, the TCG advocates using a secure hardware device to both verify the boot sequence and authenticate this verification. The TPM is a special chip embedded in a smart card soldered to the motherboard. Basically, the TPM is a microcontroller that stores keys, passwords, and digital certificates. Security processes, such as digital signatures and data decryption, are protected through the secure TPM subsystem. Today, TPM is available in some computers but not all of them, which underscores the need for an additional way to provide two-factor authentication prior to booting the operating system. In our lab, we ve explored using a for trusted computing, both as a general design and as a real prototype. The user controls the (which is a smart card with a USB interface), and because it s external to the TPM or any other integrity system, more than one can be used on the same platform (thus different users can have different loader, operating system, and application software configurations). The approach gives platforms that don t have an installed TPM some of the benefits of TPM-like integrity checks. The approach Our use of the approach is designed both to provide boot integrity and to enforce access control. The basic idea is that the host computer actually boots from a USB disk loaded with the operating system and the loader. Figure 1 shows how we use a with a modified Grand Unified Bootloader (Grub; software/grub/) to get a trusted boot process; in our scheme, the is an extended smart card device with a USB interface. Due to its size, Grub boots in stages. Stage 1 is the main boot record (MBR), which merely loads the next stage. Stage 1.5 is also quite small, but it can understand file systems. Depending on what file system holds the Stage 2 loader, Grub uses a different Stage 1.5 it s even optional in some circumstances. Stage 2 is the meat of the loader and contains many features and options. Booting from the USB disk works as follows: Grub generates Stage 1, Stage 1.5, and Stage 2 first, and then command dd writes Stage 1 to the first sector of the USB 34 PUBLISHED BY THE IEEE COMPUTER SOCIETY /06/$ IEEE IEEE SECURITY & PRIVACY

2 Related work in secure bootstrapping Implementing trusted computing requires a secure and reliable bootstrap architecture, as other research has proposed. 1,2 In AEGIS, William Arbaugh and his colleagues implement secure booting by changing the BIOS. 1 Starting from the basic layer, which is in the ROM and assumed to be trusted, the ROM hashes all the other layers and verifies them against a stored signature. The trust in this system thus depends on the basic layer s integrity. saegis is an extension of AEGIS that implements secure booting in the absence of a trusted system administrator. 2 It uses a smart card to store certificates and trusted system hashes, and it lets the user decide whether a system component is trusted. However, saegis has some limitations: it doesn t have random number generators, verification doesn t use a hash in the smart card, the smart card holds only one hash, and the kernel hash, m, isn t included in the message the smart card sends to the workstation. Both of these projects are based on a modified BIOS, which prevents wider usage of them. The approach we describe in the main text is much more flexible than either AEGIS or saegis because it s multiboot-compatible and doesn t require BIOS modification. References 1. W.A. Arbaugh, D.J. Farber, and J.M. Smith, A Secure and Reliable Bootstrap Architecture, Proc. IEEE Symp. Security and Privacy, IEEE CS Press, 1997, pp N. Itoi et al., Personal Secure Booting, Proc. 6th Australasian Conf. Information Security and Privacy, Springer-Verlag, 2001, pp disk. Grub s root command and setup command tell Stage 1.5 where Stage 2 is located. Finally, the CMOS sets the BIOS to boot from the Universal Serial Bus- Hard Disk Device (USB-HDD). When the PC is turned on, BIOS then loads the MBR from the USB disk. In Figure 1, the BIOS loads the MBR (which is Grub s Stage 1) from the boot device. Next, Stage 1 loads the first sector of Stage 1.5, which is called Start, and Start then loads the rest of Stage 1.5 and passes control to it. Stage 1.5 loads Stage 2 from a list of sectors (Stage 2 provides a menu interface to select which kernel or multiboot modules to load). Stage 2 then gives control to the kernel. Grub also uses the for verification. During system startup, the bootstrap process must perform two authentications before Grub Stage 1.5 can load Stage 2 into memory. The host and the have a mutual authentication, and the user is authenticated to the via a personal identification number (PIN). After both of these authentications, Grub s Stage 1.5 reads Stage 2 information from the USB disk, computes a hash value of Stage 2, and compares this value with the one stored in the. If they match, Stage 1.5 loads Stage 2 into memory and then transfers control to Stage 2, which checks the operating system kernel s integrity. If everything s okay, the bootstrap process continues; if not, it halts. Assuming everything is fine, the PC operates as normal when the PC is booted with our, it knows that it has a legitimate user and that the operating system was verified in the boot stage. hardware A smart card is a secure way to store certificates and keys. Along with hardware tokens, smart cards deliver user benefits in four major areas: easy portability of user credentials and secrets between several computing platforms, Grub Stage 1.5 modified OS kernel Grub Stage 2 Grub Stage 1.5 Boot user authentification Mutual authentification between and host Start.s Grub Stage 1 (MBR) BIOS U-key Figure 1. Trusted boot process. Our approach combines a with a modified Grand Unified Bootloader (Grub) to boot the operating system. The modified Stage 1.5 performs three authentication processes. It also verifies Stage 2 s integrity before it s loaded. Before the operation system kernel is loaded, its integrity is verified in Stage 2. drastic simplification of platform and user management, better protection of personal credentials and secrets, and a higher level of personal privacy. MACs of Stage 2, kernel Boot Check MAC Refer However, smart cards need a special reader, which often prevents their wider usage. A has a wider application because of its portability without a special reader. Figwww.computer.org/security/ IEEE SECURITY & PRIVACY 35

3 +5V D+ D GND USB connector Serial interface engine 32 bits GPIO VCC RST D GND Figure 2. architecture. Its main functional part is the smart card. User interface Function layer Driver layer hardware USB transceiver Authentication Authentication module in Grub Secure boot module in Grub Real-mode driver Mask ROM 16-bit RISC prosessor RAM Data Data Functions Secure boot application trusted function call Manage module Setup and maintain module U-key function interface BIOS function call interface USB host controller driver Smart card Function call interface driver USB Protocol stack OS kernel Smart card Software at host side Figure 3. s software layers. It s composed of three layers the driver layer, the function layer, and the user interface layer. ure 2 illustrates the s hardware components. U- Keys are common, but we designed this one ourselves. hardware has five components 1 a USB connector, a USB transceiver, a serial interface engineer (SIE), a microcontroller unit (MCU), and a standard smart card that both provide authentication and protect important data. software In our approach, we used a as a token for secure authentication and storage. Accordingly, we categorize the related software into two parts depending on function authentication and secure boot functions appear in the boot phase, and the application s trusted function call resides in the operating system s user mode (see Figure 3). The application s trusted function call interface gives applications in the user mode access to the s functions. If the user application needs an integrity check on its configuration files, for example, it can use this interface to achieve that goal. The application s trusted function call interface is composed of three parts: the setup and maintain module, the manage module, and the function call interface. To provide computer boot integrity and enforce access control, the must be initialized and loaded with configuration information for each of these parts. The setup and maintain module initializes the and provides cryptographic hashes to the file system s storage. Although the smart card file system is defined in ISO ( it s officially specified as a low-level hierarchy-based file system that s organized into a collection of three elementary file types master file (MF), dedicated file (DF), and elementary file (EF). The manage module sets the s access control information, such as who can read information from the s memory. Grub s authentication and secure boot modules provide the authentication and secure boot functions. After configuration, the user can employ the at boot time, before the operating system is loaded (when only the BIOS is running). A real-mode driver gives access to the at boot time. Real-mode driver From our earlier description, we know that to access the in Stage 1.5, we should communicate with the through a USB port before the operating system is loaded. This means we need a real-mode driver. At the time of our research, such a driver didn t exist, so we created one. Applications rely on the operating system s USB driver (USBD) to access the USB device; the USBD layer relies on a common interface to the hardware, which is called the host controller interface (HCI). Before the operating system is loaded we can t access the USBD, so to access the USB device during the booting phase, we need to get to the HCI directly. To date, two interfaces are de- 36 IEEE SECURITY & PRIVACY SEPTEMBER/OCTOBER 2006

4 fined between the host and the HCI layer: Intel s Universal HCI (UHCI) Specification 2 and the Open HCI Specification. 3 We used the UHCI because most motherboards use Intel chips. The UHCI consists of two parts, the host controller driver (HCD) and the host controller (HC). The HCD interprets requests from the USBD and builds data structures such as the frame list, transfer descriptor (TD), queue head (QH), and data buffer for the HC. The HCD builds these data structures in system memory, and they contain all the necessary information to provide end-toend communication between client software in the host and peripheral devices on the USB. The HC resides as function number two inside the peripheral component interconnect (PCI) South Bridge chip. 4 This location turns the USB controller into a member of the PCI-to- ISA Bridge family of devices, together with the proper ISA Bridge and the Integrated Drive Electronics (IDE) controller inside the Intel PIIX4 device. Figure 4 shows the relationship between the PCI South Bridge chip and the. The HC is accessible through the PCI configuration space; the real-mode driver s task is to drive the through the HC in the PCI Bridge chip. Figure 5 shows how a frame list (of up to 1,024 entries) handles scheduling with the UHCI. Each entry is a pointer to the first structure to process in a given frame. The 4- Kbyte frame list table is aligned on a 4-Kbyte boundary. The HC accesses the frame list from the frame list base address register and the frame number. The register provides the location of the frame list table in system memory, and the frame number provides the index into the list. The HC moves data between system memory and devices on the USB by executing the HCD-generated schedule lists; the HC also reports the status of transactions on the USB to the HCD. The HC walks the schedule list one entry at a time as it generates the next 1-ms frame. With the, control and interrupt transfers shift commands and data between host and device. First, the HCD creates the transfer descriptions (TDs), which express the characteristics of the host-requested USB transaction. Then the HCD creates queue heads (QHs), which support the control and interrupt transfers basic requirements. After this step, the HCD links the TDs to the QH, and the QH to the frame list. When these steps complete, the run bit in the command register schedules the data transfers. The HC fetches the TDs and generates the proper transaction on the USB. When it finishes, the transaction s status is stored in the TDs. USB bus PCI bus PCI South Bridge/USB controller ISA bus IDE bus Figure 4. The relationship between the peripheral component interconnect (PCI) South Bridge chip and the. The is driven through the USB host controller (HC) via the PCI South Bridge chip. 31 Frame list base address register Base Frame pointer Frame list, up to 1,024 entries Frame pointer Frame pointer Q Q Q Index 00 configuration The s configuration entails loading the cryptographic hashes for Grub Stage 2 and the operating system kernel onto the itself. File integrity information is also loaded into the at this time (for the integrity check after the operating system has run). To perform authentication at boot time, the administrator can also load the key for internal authentication (K I ), the key for external authentication (K E ), and the user PIN. T T T Frame pointer Q T Frame number register Queue heads (QHs) interrupt QH Hard disk device T Terminate Q Transfer description or queue head Figure 5. Data transfer schedule. To make the host controller (HC) control the, we need a data transfer schedule between the HC and the. TD TD TD Link pointer Element link pointer null IEEE SECURITY & PRIVACY 37

5 is authenticated to host Host is authenticated to PIN verify Figure 6. Grub authentication. It s composed of user private identification number (PIN) authentication and mutual authentication between the and the host. Our modified Grub Once our was functional, the next step was to integrate it into the boot process. Naturally, the first step in this chain is the BIOS; the next step is to modify the boot loader. In our current prototype, we used Grub instead of the Linux loader (LILO) as the boot loader for two reasons: Our operating system, Kylin, is based on a microkernel that needs a boot loader that can support the multiboot standard. LILO doesn t, but Grub can boot myriad operating systems, including DOS, Windows, FreeBSD, and Linux. The Grub boot loader has a more flexible architecture. When LILO boots a Linux kernel, for example, it reads it directly from the disk by using a map file that holds previously stored kernel location information. When we move the kernel or the disk geometry changes, we have to run LILO to generate a new map file. Grub was designed to overcome this problem: because it understands partitions and file systems, it can load a kernel that it wasn t told about previously. No map file is necessary, and Grub doesn t need to be re-run after installing a new kernel. For more information about Grub s specifications, see Authentications added in Grub During system start up, the bootstrap process must perform three authentications to complete the boot sequence, as Figure 6 shows: First, the authenticates to the host. To do this, the must make available a secret shared with the R 1 {R 1 } K I Get random R 2 {R 2 } KE Success/failure {PIN} K Success/failure Host host (in this case, the K I ). The ISO7816 standards for smart cards provide basic functionality for authentication, so the ISO7816 internal authenticate command returns a keyed hash of a short message (the challenge) to authenticate the card to the outside world. Next, the host is authenticated to the. To do this, the host must make available a secret shared with the U- Key (in this case, the K E ). The external authenticate command conditionally updates the security status by using the card s computation result (yes or no) based on a challenge the card previously issued (such as a get challenge command). Mutual authentication is reached in this step. Finally, the user is authenticated to the via a PIN. The verify command compares the card with the verification data sent from the HCD, with the reference data stored in the card. Only after PIN authentication success can the user communicate with the rest of the application. As a security feature, the U- Key administrator can set a maximum number of PIN retries. Once the count reaches zero, the will permanently block access to the card s contents. Once both the user and the mutual authentication between the and the host are successful, the lets the PC read information from the s memory and the boot sequence continues; otherwise, the boot process stops. Integrity check function Because the boot sequence precedes the application program s execution and even that of the operating system itself antiviral software is ineffective at preventing bootsector viruses. Thus for software defenses to be effective, we need a clean boot. Figure 1 shows the integrity check process. We modified Grub s Stage 1.5 slightly: prior to loading Stage 2 into the main memory, Stage 1.5 computes and verifies a cryptographic hash of Stage 2 against a stored value for it in the. If the value is valid, control is passed to Stage 2. We then modified Stage 2 slightly: prior to loading the operating system kernel into the main memory, Stage 2 computes and verifies a cryptographic hash of the operating system kernel against a stored value for it in the U- Key. If the value is valid, control is passed to the operating system kernel. At this point, the now sees that this particular kernel was booted in a trusted fashion. Any integrity failures identified in this process will cause the boot process stop, and if everything is fine, the system proceeds normally. At configuration time, the system executable s cryptographic hash can also be loaded into the. After the operating system boots, the comparison of executable hashes with those stored on the provides a virus detection mechanism that s difficult to defeat. This approach is consistent with a recent trend to validate file 38 IEEE SECURITY & PRIVACY SEPTEMBER/OCTOBER 2006

6 Peripheral Devices integrity rather than scan for known virus signatures. Although our approach isn t a virus checker, it s possible to detect modified versions of those files whose hashes are stored on the. The user can quickly learn if an executable is suspect before it runs. s attacks that modify the operating system itself become more common, we ll see a stronger demand for secure bootstrapping. Although our scheme isn t a full TPM, it s a good alternative for improving computer security. Unfortunately, the approach s main limitation is that the integrity of both the MBR and Stage 1.5 isn t verified during the bootstrap process. As we ve shown here, we can boot a PC from the USB, but the place where the MBR is stored is much more secure than the hard disk. Our approach s limitation is that it requires two USB ports and two USB devices to achieve a trusted boot process. In fact, we can integrate these two devices into one, which can function both as a smartcard and as a USB disk. We ve designed such a device in the Windows environment, but how to make its real-mode driver is the next step of our work. We ve done some research into this material, but so far, we have yet to implement it. A References 1. P. Shuanghe, T. Weimin, and M. Yali, The Implementation of T=0 Protocol for a Smartcard Based on a USB Control Chip, J. Computer Applications, vol. 24, Oct. 2004, pp Universal Host Controller Interface Design Guide, v. 1.1, Mar. 1996; 3. Open Host Controller Interface Specification for USB, v. 1.0a, Sept. 1999; 4. Intel 82801DB I/O Controller Hub 4 (ICH4) data sheet, Intel, May 2002; datashts/ htm. Peng Shuanghe is a lecturer in the Research Center of Information Security Architecture at Beijing Jiaotong University. Her research interests include information security and embedded systems. Shuanghe has a PhD in computer application technology from the School of Computer and Information Technology at Beijing Jiaotong University. Contact her at shhpeng@ sohu.com. Han Zhen is a professor in the Research Center of Information Security Architecture at Beijing Jiaotong University. His research interests include graphics and information security. Zhen has a PhD in application mathematics from the Institute of Computing Technology in the Chinese Academy of Sciences. Contact him at hz@computer.njtu.edu.cn. F E AT U R I N G IN 2007 IEEE Pervasive Computing delivers the latest peer-reviewed developments in pervasive, mobile, and ubiquitous computing to developers, researchers, and educators who want to keep abreast of rapid technology change. With content that s accessible and useful today, this publication acts as a catalyst for progress in this emerging field, bringing together the leading experts in such areas as Hardware technologies Software infrastructure Sensing and interaction with the physical world Graceful integration of human users Systems considerations, including scalability, security, and privacy Healthcare Building a SensorRich World Urban Computing Security & Privacy Subscribe Now! V I S I T IEEE SECURITY & PRIVACY 39