JP4837985B2 - System and method for securely booting a computer having a trusted processing module - Google Patents

Description

  The present invention relates generally to the field of computing. More specifically, the present invention improves computer security by preventing unauthorized modification of data used during boot and preventing post-boot access to resources that are only needed during boot. Systems and methods for enhancing are provided.

  Security has become a widespread problem for computer users. Depressions that use viruses, worms, Trojan horses, identity theft, illegal copying of software and media content, and threats of data corruption are rampant. Operating systems can provide a number of security features to prevent such attacks. However, operating system security features are disabled when they are disabled. If an attempt is made to disable these security features, it is likely to be attempted during the operating system boot. After booting, the operating system can have a number of suitable functions in place to protect the operating system itself and the data and processes managed by the operating system. However, during booting, these functions cannot yet be initialized and are vulnerable to bypass and / or tampering.

  The exemplary security functions currently used by the operating system are the encrypted file system (EFS) and the trusted platform module (TPM). The EFS function encrypts the selected confidential data. The operating system does not need to access EFS data until the user logs on. After the operating system boots, the user can provide a password for the logon process. This password permits access to a decryption key that can decrypt the EFS data. As an example, the MICROSOFT WINDOWS® operating system relies on the availability of SYSKEY to perform the correct performance of these processes, thereby providing a system key or “SYSKEY” that is used to protect various processes. Is used. For example, the key required to decrypt EFS data stored in encrypted form by the operating system can be derived from SYSKEY.

  Thus, the keys required to perform restrictive actions are protected by the logon procedure. In general, a user must correctly authenticate himself before starting to use the system. Key usage is only enabled if the user authenticates correctly. However, using a logon procedure to protect access to the key means that the operating system has read the correct logon procedure and that the use of the key is another way because of the running rogue code. Suppose that it was not enabled by If an unrecognized operating system loader is used during boot instead of the correct operating system loader, the unrecognized loader may cause the operating system to load an unrecognized logon program. This unrecognized logon program can enable the use of EFS keys without entering a proper password. Loading the operating system presents an opportunity for a security breach, so to protect the key in these situations, load the operating system under conditions that ensure that the operating system loads correctly. It is necessary.

  Since EFS is a function supported by the booted operating system, it has no similar effect on protecting certain data that leaks during the boot process. EFS is a secret required for some system services, databases used by network services (eg, personal servers or public web servers), and RAS credentials for connecting to corporate domains The user data required before the user logs on cannot be protected.

  A trusted processing module (TPM) ensures the reliability of software running on the computer. In general, this is accomplished by submitting reliable data measurements to the TPM and relying on the TPM to determine what the measurement should be. Computer security often relies on being able to predict the behavior of software components. In general, system security arises from the premise that well-known programs that operate from a well-known good state operate in a predictable manner. On the contrary, in general, by replacing or changing a well-known program, or by executing the program in a state where its operation is not understood, a security breach (in a way other than that designed by the designer) (It can include operating the system). Thus, one aspect of providing security for a computing environment includes the step of confirming that a well-known program is used and that the process proceeds from a well-known good state. Since measurements such as the hash value of the data match the previously sealed value in the TPM, the TPM accomplishes this by verifying what the data should be. To do.

  Like EFS, TPM has been successfully used to provide certain guarantees regarding the integrity of applications running on booted computers. There are also a number of additional limitations on the TPM. For example, a machine that uses a TPM in a standard way cannot be reconfigured in the field (eg, inserting a network card into a laptop during a meeting, etc.). TPM places severe limitations and complexity on the initialized operating system.

  Most of today's TPMs are currently compliant with the TRUSTED COMPUTEING GROUP (TCG) standard named “Trusted Platform Module (TPM) Specification Version 1.2” available in Non-Patent Document 1 is doing. A TPM is a subsystem that can be incorporated into a computing platform to establish trust in code executed by the platform. Standardization of mechanisms for establishing reliable code is beneficial, as it allows the security and cryptographic community to evaluate mechanisms for providing security and deepens customer understanding and trust in new software features. That is. This also promotes innovation in the implementation and improvement of standards as considered and promoted by TCG®. “Manufacturers will compete in the market by installing subsystems with varying capabilities and cost points,” as stated in the TCG® specification.

  The above exemplary security mechanism used by the operating system is supplemented by several techniques for securing boots. Machine password authentication can be used to protect the secret using the machine's global password. However, this requires entering a password before the machine boots. The first security flaw is that many users of the machine must share a password. A second flaw is that ease of use issues arise because a typical user interface for password entry cannot be provided. This is particularly troublesome for tablet PCs. Machine global passwords are often written on paper and placed in front of the machine. Thus, while passwords are valid, they do not allow the type of advanced user protection that is frequently desired.

Second, the secret can be stored on removable media. This feature is theoretically effective from the viewpoint of security, but it is often a problem in practice. The basic problem in this case is that removable media is most often left inside the machine to ensure proper system operation for use.
Without the proper assurance of a secure operating system boot, the user's ability to protect data on a computer is not the security features of the operating system running on the computer, Limited by building security. With the popularity of laptops and theft of computers, especially laptop theft, a solution that allows operating system security to remain un compromised when a computer is in the hands of a thief The method is preferred.

  Systems and methods that use TPM to secure the boot process remain largely unexplored. In addition to using TPM in the boot process, systems and methods for maintaining the boot process and controlling access to data on such computers have proven useful. A description of such systems and methods can be found in US Pat. Patent Document 4 is also generally related to the present invention.

No. 34 / T. No. 34 / T. No. 34 / T. No. 34 / T. No. 34 / T. No. 34 / T. No. 34 / T. No. 34 / T. 46 / T. No. 34 / T. 46 / T. U.S. Patent No. (Attorney Docket No. MSFT8601 / Attorney Docket No.MSFT8601) entitled "Systems and Methods for Updating a Secure Boot Process on a Computer with a Hardware Security Module" US Patent Application No. ___ (Attorney Docket No. MSFT4635 / 31227.) Entitled "Systems and Methods for Controlling Access to Data on a Computer with a Secure Boot Process" US patent application Ser. No. 10 / 882,134 filed Jun. 30, 2004, entitled “Systems and method for protected operating system boot use state validation” https: // www. trustedcomputing group. org / home

  In view of the above, the present invention provides a system and method for securely booting a computer having a trusted platform module (TPM) for verifying the integrity metrics of software components. The TPM used with the present invention can conceal secrets in multiple platform configuration register (PCR) values. PCR values can be obtained by measuring boot components. If the boot component has not been modified since the secret was hidden, the secret can be obtained for proper system boot. The expected hash value of the boot component can be placed in the PCR and the secret can be disclosed if the expected value is correct. The secret can then be used to decrypt the actual boot component from the location on the disk. A hash value of the decrypted boot component can be calculated and the result compared to the expected value. Another example involves using two secrets that can be concealed in the PCR value that can be obtained at different points in the boot process. The first secret is accessible only when the first plurality of PCR values are read, and the second secret is accessed only after one or more of the first plurality of values are replaced with new values. Is enabled, which necessarily disables further access to the first secret to allow access to the second secret. Other advantages and features of the invention are described below.

  The system and method for securely booting a computer according to the present invention will be further described with reference to the accompanying drawings.

  Certain specific details are set forth in the following description and drawings in order to provide a thorough understanding of various embodiments of the invention. However, in order to avoid unnecessarily obscuring the various embodiments of the present invention, certain well-known details that are often associated with computing and software technology are not set forth in the following disclosure. Moreover, those skilled in the relevant art will understand that other embodiments of the invention may be practiced without one or more of the details described below. Finally, in the following disclosure, various methods are described with reference to steps and sequences, which are for the purpose of clearly implementing embodiments of the present invention. The sequence of steps should not be deemed necessary for the practice of the present invention.

  The following detailed description generally follows the summary of the invention as described above, and further describes and develops definitions of various aspects and embodiments of the invention as appropriate. For this purpose, this detailed description will first describe the computing environment of FIG. 1 suitable for implementing software and / or hardware techniques related to the present invention. To emphasize that modern computing technology can be implemented across a number of separate devices, a networked computing environment is shown in FIG. 2 as an extension of the basic computing environment.

  Next, an overview of computing platforms utilizing a hardware security module (HSM) is provided in conjunction with FIG. 3 to see how measurements can be submitted to the HSM. If the value is correct, explain what can be configured to return the key to system resources. Note that the HSM shown in FIG. 3 is a TPM that is readily recognized by those skilled in the art. Also, further processing of software components involved at boot time or thereafter may be subject to a secret disclosure protected by the TPM. Next, the use of the TPM by the software component in the boot process is illustrated in FIG. FIG. 5 illustrates one general pattern for using a TPM by a software component such as that of FIG. 4, where loading and execution of the next software component is execution of the next component. The condition is to check the hash value of a possible code.

  In FIG. 5a, FIG. 6, FIG. 7 and FIG. 8, aspects of the use of TPM registers called platform configuration registers (PCR) in the boot process are described in more detail. FIG. 5a illustrates a system and method for ensuring that the boot process cannot proceed unless a particular set of boot components are in place. FIG. 6 demonstrates an example of the system and method shown in FIG. 5a, where successfully booting a computer is associated with successfully encrypting and measuring an exemplary component or boot manager. FIGS. 7 and 8 illustrate the need for booting after the boot process successfully boots the operating system and no longer requires these resources (typically residing on one or more disk partitions). Indicates a mechanism to prevent access to system resources

Exemplary Computing and Networking Environment The computing system environment 100 of FIG. 1 is only one example of a suitable computing environment and is intended to suggest any limitation as to the scope of use or functionality of the invention. is not. Neither should the computing environment 100 be interpreted as having any dependency or requirement on any one or combination of components illustrated in the exemplary operating environment 100.

  The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the present invention include, but are not limited to, personal computers, server computers, handheld or laptop type devices. , Multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing including any of the above systems or devices Environment etc. are included.

  The invention can be implemented in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

  With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 121. The components of the computer 121 include, but are not limited to, a processing unit 101, a system memory 103, and a system bus 102 that couples various system components including the system memory to the processing unit 101. Can do. The system bus 102 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. . By way of example, and not limitation, such architectures include industry standard architecture (ISA) bus, micro channel architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standard Association (VESA) local bus, and mezzanine bus Including the Peripheral Component Interconnect (PSI) bus, also known as

  Although the HSM is not shown in FIG. 1, such a device can be part of a computer implementing the present invention. As described below with reference to FIG. 3, FIG. 3 shows an HSM (TPM in the embodiment of FIG. 3) integrated with the components of the computer. In typical environments, hardware welded to the motherboard or integrated with other hardware components of the computer such as the chipset or that of FIG. 1 to provide a range of security functions. It can be a hardware chip. However, for the purposes of this specification, the HSM can be implemented in hardware or software and is a reliable function necessary for the operation of the present invention, i.e., comparison and verification of measurements submitted to the HSM, It should also be understood that it is broadly defined as a disclosing functional unit of a key for access to an encrypted memory resource. The TPM may also provide a range of other functions, as described in the TCG® specification for the industry standard TPM.

  Computer 121 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 121 and includes both volatile and nonvolatile media, and both removable and non-removable media. By way of example, and not limitation, computer readable media can include computer storage media and communication media. Computer storage media is volatile and non-volatile media implemented in any method or technique for storage of information such as computer readable instructions, data structures, program modules, or other data, and removable Includes both media and non-removable media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical disc storage device. , Magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to store desired information and that can be accessed by computer 121. Communication media typically embodies computer readable instructions, data structures, program modules or other modulated data signals such as carrier waves or other data in other transport mechanisms and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, wireless media such as acoustic, RF, infrared, or other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

  The system memory 103 includes computer storage media in the form of volatile and / or nonvolatile memory such as read only memory (ROM) 104 and random access memory (RAM) 106. A basic input / output system 105 (BIOS) that includes basic routines that help transfer information between elements in the computer 121 during startup, etc., is generally stored in the ROM 104. The RAM 106 generally includes data and / or program modules that are immediately accessible to and / or currently operating by the processing unit 101. By way of example and not limitation, FIG. 1 shows operating system 107, application program 108, other program modules 109, and program data 110.

  The computer 121 may also include other removable / non-removable, volatile / nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 112 that reads from or writes to a fixed non-volatile magnetic media and a magnetic disk drive that reads from or writes to a removable non-volatile magnetic disk 119. An optical disk drive 120 that reads from or writes to 118 and a removable non-volatile optical disk 253 such as a CD ROM or other optical media is shown. Other removable / non-removable, volatile / nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital Includes versatile discs, digital videotapes, solid state RAM, solid state ROM, etc. The hard disk drive 112 is typically connected to the system bus 102 through a fixed memory interface, such as interface 111, and the magnetic disk drive 118 and optical disk drive 120 are generally removable memory, such as interface 117. Connected to system bus 102 through an interface.

  The drive described above and shown in FIG. 1 and associated computer storage media store computer readable instructions, data structures, program modules, and other data for the computer 121. In FIG. 1, for example, hard disk drive 112 is shown as storing operating system 113, application programs 114, other program modules 115, and program data 116. Note that these components can either be the same as or different from operating system 107, application programs 108, other program modules 109, and program data 110. Operating system 113, application program 114, other program modules 115, and program data 116 are given different numbers here, at least to indicate that they are different copies. A user may enter commands and information into the computer 121 through input devices such as a keyboard 128 and pointing device 127, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) can include a microphone, joystick, game pad, satellite dish, scanner, and the like. These and other input devices are often connected to the processing unit 101 through a user input interface 126 coupled to the system bus, such as a parallel port, a game port, or a universal serial bus (USB). It can also be connected by other interfaces and bus structures. A monitor 139 or other type of display device is also connected to the system bus 102 via an interface, such as a video interface 232. In addition to the monitor, the computer can also include other peripheral output devices such as speakers 138 and printer 137 that can be connected through output peripheral interface 123.

  Computer 121 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 131. The remote computer 131 can be a personal computer, server, router, network PC, peer device, or other common network node, and is generally of the elements described above in connection with the computer 121. Only a memory storage device 132 is shown in FIG. 1, including many or all. The logical connections shown in FIG. 1 include a local area network (LAN) 135 and a wide area network (WAN) 130, but can also include other networks. Such network environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

  When used in a LAN network environment, the computer 121 is connected to the LAN 135 through a network interface or adapter 134. When used in a WAN network environment, the computer 121 typically includes a modem 129 or other means for establishing communications over the WAN 130, such as the Internet. The modem 129, which can be internal or external, can be connected to the system bus 102 via a user input interface 126 or other suitable mechanism. In a networked environment, program modules illustrated in connection with computer 121 or portions thereof may be stored in a remote memory storage device. By way of example and not limitation, FIG. 1 illustrates remote application program 133 as residing on memory device 132. It will also be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

  It should be understood that the various techniques described herein may be implemented with hardware or software, or a combination of both as required. Thus, the method and apparatus of the present invention, as well as certain aspects or portions thereof, may be embodied in a tangible medium, such as a floppy diskette, CD-ROM, hard drive, or any other machine-readable storage medium. Program code (ie, instructions), where the machine implements the invention when the program code is read into and executed by a machine, such as a computer. It becomes a device for. When executing program code on a programmable computer, the computing device typically includes a processor, storage media readable by the processor (including volatile and non-volatile memory and / or storage elements). , At least one input device, and at least one output device. One or more programs may perform or utilize the processes described in connection with the present invention using, for example, APIs, reusable controllers, and the like. Such programs are preferably implemented in a high level procedural or object oriented language to communicate with a computer system. However, if desired, the program can be implemented in assembly language or machine language. In either case, the language can be a compiled or interpreted language and can also be combined with a hardware implementation.

  Although the exemplary embodiments refer to the use of the invention in the context of one or more stand-alone computer systems, the invention is not so limited, rather it is a network computing environment or It can be implemented with any computing environment, such as a distributed computing environment. Furthermore, the present invention can be implemented in or across multiple processing chips or devices, and can also be stored across multiple devices. Such devices can include personal computers, network servers, handheld devices, supercomputers, or computers embedded in other systems such as cars and aircraft.

  In FIG. 2, an exemplary networked computing environment is provided. One skilled in the art can appreciate that a network can connect any computer or other client or server device, or can be connected in a distributed computing environment. In this regard, any computer system or environment having any number of processes, memories, or storage units, and any number of applications and concurrent processes is suitable for use with the provided systems and methods. it is conceivable that.

  Distributed computing shares computer resources and services by exchange between computing devices and systems. These resources and services include information exchange, file caching and disk storage. Distributed computing takes advantage of network connectivity and allows clients to leverage the overall power to benefit the entire enterprise. In this regard, various devices can have applications, objects, or resources that can be related to the processes described herein.

  FIG. 2 provides a schematic diagram of an exemplary networked or distributed computing environment. This environment includes computing devices 271, 272, 276 and 277 and objects 273, 274 and 275 and a database 278. Each of these entities 271, 272, 273, 274, 275, 276, 277, and 278 may include or utilize programs, methods, data stores, programmable logic, and the like. Entities 271, 272, 273, 274, 275, 276, 277, and 278 can span parts of the same or different devices such as PDAs, audio / video devices, MP3 players, personal computers, and the like. Each entity 271, 272, 273, 274, 275, 276, 277, and 278 communicates with another entity 271, 272, 273, 274, 275, 276, 277, and 278 via the communication network 270. be able to. In this regard, any entity can be responsible for maintaining and updating the database 278 or other storage element.

  This network 270 may itself include other computing entities that provide services to the system of FIG. 2, and may itself represent a number of interconnected networks. In accordance with aspects of the present invention, each entity 271, 272, 273, 274, 275, 276, 277, and 278 is one of the other entities 271, 272, 273, 274, 275, 276, 277, and 278. Alternatively, APIs or separate functional program modules that can utilize other objects, software, firmware, and / or hardware to request multiple services can be included.

  It will also be appreciated that objects such as 275 can be hosted on another computing device 276. Thus, although the physical environment shown shows the connected device as a computer, such illustrations are merely exemplary, and the physical environment could alternatively be a PDA, television, MP3 player, etc. Can be shown or described as including various digital devices and interfaces, software objects such as interfaces, COM objects, and the like.

  There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems can be connected to each other by wired or wireless systems, local networks or wide area distributed networks. Currently, many networks provide infrastructure for wide area distributed computing and are coupled to the Internet, which includes many different networks. Any such infrastructure can be used with the provided systems and methods, whether or not coupled to the Internet.

  The network infrastructure enables hosts in network topologies such as client / server, peer-to-peer, or hybrid architectures. A “client” is a member of a class or group that uses the services of another class or group to which it is not related. In computing, a client is a process that requests a service provided by another program, that is, roughly a set of instructions or tasks. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client / server architecture, particularly a networked system, a client is typically a computer that accesses shared network resources provided by another computer, such as a server. In the example of FIG. 2, depending on the situation, any entity 271, 272, 273, 274, 275, 276, 277, and 278 can be considered a client, a server, or both.

  A server is a remote computer system that can be accessed across a remote network, such as the Internet, or a local network, although it cannot be generally stated. Client processes can be active in the first computer system and server processes can be active in the second computer system and communicate with each other over a communication medium, thereby providing distributed functionality This allows a large number of clients to use the information collection capability of the server. Any software object can be distributed across multiple computing devices or objects.

  The client and server communicate with each other using functions provided by the protocol layer. For example, HyperText Transfer Protocol (HTTP) is a common protocol used in conjunction with World Wide Web (WWW) or “Web”. In general, a computer network address, such as an Internet Protocol (IP) address, or other reference, such as a Universal Resource Locator (URL), can be used to identify server computers or client computers from each other. The network address can be referred to as a URL address. Communication can be provided through communication media, for example, clients and servers can be coupled together via a TCP / IP connection for high volume communication.

  In view of the various computing environments that can be constructed according to the general framework of FIG. 1 and the additional diversity that can arise in computing in a network environment such as that of FIG. 2, the systems and methods provided herein are It cannot be construed as limited to any particular computing architecture. Instead, the present invention should not be limited to any single embodiment, but rather the scope of the present invention should be construed in breadth and scope in accordance with the appended claims.

Exemplary TPM Secure Boot Sequence Embodiments of the present invention use a TPM in a secure boot process. The TPM is shown in the context of the computer architecture of FIG. The TPM considered for use in embodiments of the present invention can be TCG® 1.2 compliant, but validates measurements such as those placed in PCR and the measurements are correct HSM can be used to disclose the secret in some cases.

  In this regard, FIG. 3 shows CPU 300 having access to memory 305 in a highly generalized diagram of a computer such as that of FIG. The CPU 300 can rely on the TPM 301 for some security functions. In general, the CPU 300 first measures data included in the boot process, and these measured values can be securely stored in the TPM 301 as indicated by the concealed PCR value 304. In various embodiments, the various PCR values 304 and 303 shown in the drawings herein are actually one or more extended by algebraic expressions as defined in the TCG® 1.2 specification. Note that it can be stored in multiple single destinations.

  The secret 302 can be concealed in a specific PCR value 304 in the TPM 301. In order to retrieve the secret 302 from the TPM 301, the correct PCR value must be entered into the PCR 303. These correct values can be obtained by measuring the same data that was measured to obtain the PCR value 304 concealed in the TPM 301. A large number of secrets 302 can be concealed within the various PCRs 304. For example, in order to retrieve the first secret A, the correct value needs to be stored in PCR [1], PCR [2], and PCR [3]. To obtain the second secret B, a fourth correct value is required in PCR [4].

  When a measurement value that does not match the value of the measurement value concealed in the TPM 301 is placed in the PCR 303, when the TPM 301 is requested to disclose the secret 302, the disclosure fails. If the correct measurement is placed in the PCR 303, the TPM 301 can be trusted and the secret 302 can be disclosed when the disclosure of the secret 302 is required. Thus, the “correct” measurement or correct value for this application is a measurement that hides the secret 302, which allows the TPM 301 to disclose the secret 302. It should be noted that in some embodiments, the correct measurement may be a malicious code measurement. This is the case, for example, when the first measurement value 304 concealed in the TPM 301 is broken.

  The secret concealed in a specific measurement value can be any data. In general, secret 302 takes the form of a decryption key and / or a binary large object (BLOB). In general, a key provides information that can be used to decrypt data. The secret BLOB can contain keys and other useful data. In this regard, as will be appreciated by those skilled in the art, equivalents of the various techniques described herein can be constructed by replacing the key with BLOB and vice versa. Thus, if the CPU 300 submits the correct measurement value to the PCR of 303, the TPM 301 can disclose the secret 302 when the corresponding secret 302 such as a key is requested. The key from 302 can then be used to decrypt a portion of memory 305 that can be accessed by CPU 300. In an embodiment of the invention, as shown in FIG. 3, TPM 301 can be configured to allow access to three secrets A, B, and C. The secret 302 can be concealed in the various PCR values required, so that it can only be accessed after a specific measurement is made. These three keys, the three secrets, are here called the first one for boot access only, the second for volume-bound secret, and the third for password secret. .

  Activities related to the TPM can be stored in the log 307. In some embodiments, log 307 may be maintained by the computer's BIOS. Any other process may be responsible for maintaining the log 307. Thus, if data such as software component 308 or other data 309 is measured and placed in PCR 303, the measured data in log 307 can be identified. When a secret disclosure request is made, a request event can be identified in the log 307. These are only two examples of storing TPM-related activities in log 307, which can include a wide range of other events and activity records.

  In general, the TPM 301 works with Static Root of Trust Measurement (SRTM) to make reliable measurements and submit them to the TPM 301. However, other processes for making secure measurements, such as through the use of DRTM Nexus, are also available. Embodiments of the present invention can use a reliable measurement process, such as SRTM, in this manner, in which SRTM is described herein for measuring initial disk-based boot code. It can be a BIOS standard SRTM used by various software components (also called process and RTM). The system can also extend the SRTM to measure other code and important data contained in the initial stage of booting the operating system so that the initial stage of booting the operating system can be measured. Note that PCR 303 may include values obtained from either. This value may be a measure of data such as software component 308 or other data 309. The present invention is not limited to any exclusive combination of data measurements or other values placed in the PCR 303.

  In the TPM secure boot process, the configuration displayed in FIG. 3 can be used to measure the exemplary software components shown in FIG. 4 and store the measurements in PCR 303. It is known that the boot component shown in FIG. 4, specifically the disk-based code component, that can be selected to be measured by embodiments of the present invention rarely changes, Easy to be attacked. Therefore, other than through a conditional maintenance and update process as described here, relatively low costs are paid to significantly improve data security by leaving certain boot components unchanged. .

  Referring to FIG. 4, a series of software components 400-407 for providing an exemplary boot process for a computer is shown. The invention is not limited to the specific components shown or to the sequence of components. The components shown can be read continuously and start with a Core Root of Trust for Measurement (CRTM) 400, here a generalized operating system (OS) 407 as a single software component 407. End with the component. Reading a component allows the CPU to execute component instructions that allow the component to access computer resources such as memory and the CPU. If the component of FIG. 4 is malicious or broken, once it is loaded, it can be used to circumvent security measures. Thus, a process for booting a computer compatible with the present invention includes the step of measuring the component or components and placing them in one or more PCRs 303 before allowing the component to run. Depending on the secret 302 concealed in the set of reliable measurement values 304 concealed in the TPM, the boot can be successful. However, it should be noted that the present invention may also conceal malicious code measurements within the TPM. If malicious code is running during concealment, these measurements are needed for booting. Ideally, the secret is hidden in a reliable code measurement 304. If the measurements placed in PCR 303 are correct, the secret from 302 can be disclosed, allowing the machine to proceed in a secure boot state. The process of disclosing the secret 302 is shown in FIG.

  In some usage scenarios, machine owners decide that they want to “lock” their configuration and that ROM-based code has been executed in addition to what has been previously verified. It can be guaranteed that there is no. In this case, the machine owner can configure more software components (BIOS, option ROM) included in the verification process by selecting additional PCRs 302 to be used. Owners may also decide that they want to further use the Mine password that is verified by the TPM 301. This allows security to extend the above generally available in standard embodiments of the present invention and allows the user to evaluate the security of the machine against ease of use. .

  FIG. 5 illustrates a technique for using a TPM that ensures the integrity of the next software component before reading the next software component. The steps of FIG. 5 can be performed by placing appropriate instructions in a series of components, such as the components of FIG. In this regard, the process of FIG. 5 can begin 508 with the execution of the CRTM component. Components such as CRTM and some or all of the other components in FIG. 4 can support instructions to measure another component and place the result in a PCR such as from 303 in FIG. . A component that supports such instructions, sometimes referred to as Root of Trust for Measurement (RTM), can include instructions for using the SRTM as described above. Thus, if the boot block measures the boot manager, the boot block serves as an RTM for the boot manager.

  The RTM can read the next component into memory 500, then take a measurement 501 of the next component and add 502 the measurement to the PCR. If the RTM requires a secret such as a BLOB from the key or TPM 503, it can request such a secret, and the TPM will have the correct PCR for all PCRs needed to access the secret. Disclose the requested secret only when the value is read. Accordingly, secret disclosure can be attempted 504 based on information retrieved from the TPM. If the disclosure is successful at step 505, additional steps can be taken including reading the next component and other operations described below. If the disclosure is not successful, the value in the PCR may be incorrect and thus the executable code may be corrupted. An error may occur in step 507, for example, using encryption of the data on the computer's disk and ensuring that the confidential information stored on the computer is inaccessible by removing the decryption key In order to be able to take appropriate measures. Alternatively, maintain the system, for example, by restoring the system to a state that generates the correct PCR value, or authenticating the user to allow a new hidden PCR value in value 302 from FIG. A process to do so can be implemented. Such a process is described below. As shown, if no secret is required in step 503, the next component can be loaded without requiring any secret.

  4 and 5 together, an exemplary boot process compatible with the system and method of the present invention can be shown. First, the basic input / output system (BIOS) 401 can be read and the CRTM 400 can be read and measured. This measurement can be performed, for example, by performing a hash on the BIOS and then submitting the measured value of the hash to the PCR. The BIOS can then be executed and the BIOS can act as an RTM for the master boot record (MBR) 402. The MBR can be measured and stored in the PCR, and then the MBR 402 is allowed to run. The MBR can measure the boot sector component 403, which is then allowed to execute. This pattern of reading, measuring, writing to the PCR, and moving to the next component is repeated as necessary by each component 404, 405, 406, and 407 and any component within the operating system 407. Can do. As shown in FIG. 5, additional aspects of the invention include variations of this process, which can require and use a secret at any point along the way. In this regard, embodiments of the present invention provide a high degree of security through additional steps that can be performed before moving to the next component. These additional steps allow the machine to boot successfully, subject to the secret obtained by measuring the correct PCR value, so that some or all of the data used for booting is kept secret It is guaranteed that it will remain in time. Additional steps can also serve to prevent access to post-boot resources that are required during boot but are not required thereafter.

  Prior to moving on to the next component, require some of components 400-406 to retrieve a secret that can be protected information that allows access to a decryption key, BLOB, or other decryption key, etc. By doing so, the basic process of FIGS. 4 and 5 can be enhanced. Thus, embodiments of the present invention can tune the performance of useful operations by the operating system when accessing one or more secrets at strategic points in the boot process. If it is discovered that any of the measured code modules 401-406 (also referred to herein as components and / or software processes) have changed, an important secret can be hidden. Examples of secrets that can be hidden are "SYSKEY" (used by LSASS to decrypt local secrets such as passwords used by services), stored on the computer's hard drive or disk partition A volume encryption key to decrypt virtually everything, and a secret required by a high level of system protection such as EFS. Second, the high level of protection can be verified using catalogs in a more versatile way than SRTM.

  In addition to the secure boot process described herein, the systems and methods described below can be implemented to repair the machine to a state where the machine can successfully boot.

Exemplary Additional Boot Protection Techniques Multiple software components can be configured to measure the next component before moving on to the next component, as can be understood with reference to FIGS. In such a boot sequence, some additional precautions can be taken to further increase the security of the data stored on the computer. These additional precautions are the subject of this section. Any or all of the precautions described herein can be incorporated into embodiments of the invention. In one preferred embodiment, all of the precautions described herein are used, as described below. However, the present invention is not limited to such implementation.

  Referring initially to FIG. 5a, by adjusting the secret disclosure in the integrity of such a platform, computer boot can be tied to the integrity of the components that precede the operating system. First, a conceptual overview of FIG. 5a is given, and then a more detailed explanation of FIG. 5a is given.

  First, the PCR can be extended with a publicly known hash value of a software component such as a boot manager. This results in a disclosing boot secret, which is satisfactory when all preceding software components are reliable. If the boot secret can be disclosed, all previous components can be trusted. At this time, the state of a software component such as a boot manager is not known.

  The boot secret can then be decrypted, the system partition can be decrypted on the fly using the volume symmetric key, and the boot manager can be loaded into memory.

Third, the pre-authentication step can be integrated by checking the boot manager hash value in memory, which is to be decrypted, against a known hash value. If the hash values match, the boot can proceed normally. If the hash value is not correct, the PCR can be invalidated. There are at least the following ways to confirm that the hash value is correct.
a. Check the boot manager hash value against a publicly known hash value. If the system can disclose the boot secret, it knows that the publicly known hash value is valid, so implicitly, the hash value of the boot manager is used to disclose the boot blob. , The boot manager hash value is found to be valid.
b. The boot manager hash value is checked against the secret stored hash value.
c. Extend the different PCRs with a publicly known boot manager hash value and compare the two hash values.

  Referring now in more detail to FIG. 5a, at step 550, the current component or RTM is running. The current RTM can perform the following steps to move to the next software component. The expected next component measurement can be read 551 into a PCR, eg, PCR [a]. The RTM component can then attempt 552 to retrieve the secret. If PCR [a] is not read with the correct value, the current RTM is not valid and access to the secret can be denied, thereby causing a normal as described with reference to FIG. Boot is blocked. Using the secret, the next component can be decrypted 553. Since the next component is decrypted, it is impossible for a future attacker to break down, modify, and execute the next component in an unexpected manner. The next decoded component is measured 554 and the measurement can be placed in a PCR 555 such as PCR [b]. The RTM can then compare the values of PCR [a] and [b] 556. If they match, then 558 can move to the next component, which can be the next component. If they do not match, for example, by measuring some predetermined parts of the memory and putting them in these PCRs, it is possible to put an upper limit on PCR [a] and [b] in the terminal values, Normal boot can be aborted 559.

  Referring to FIG. 6, the flowchart shown shows an embodiment of the system and method introduced in FIG. 5a, where access to the critical boot components and the critical Numerous steps are shown in implementing the system and method for adjusting the integrity of the correct boot component. Although the exemplary boot component used in FIG. 6 is a boot manager, any component can be the subject of the technology demonstrated in FIG. For purposes of this description, the steps of FIG. 6 can be understood in light of FIG. Multiple software components can be executed in a continuous manner, and one or more of these can measure the next component before moving to the next component.

  In this context, a first component, such as a boot sector, can be loaded at some point in the boot process, as shown in step 612. The boot sector can then be measured and stored in the PCR according to the technique described in FIG. 5a. An exemplary PCR used in step 611 is PCR [8], but the present invention is not limited to any particular PCR. The computer can then transition to executing the boot sector 612. Here, the boot sector can serve as an RTM for the boot block, where the boot block can be measured and stored in PCR [9] 608. The computer can then transition 600 to execute a boot block. Here, the boot block can act as an RTM for the boot manager and perform additional security measures in the next step.

  In this way, the boot block can read 601 expected measurements of the boot manager into the PCR. An exemplary PCR used in FIG. 6 is PCR10. If the values read into PCR [8], [9], [10] and the previous or next PCR configured to control are correct, when such a secret is requested by the boot block, the TPM Allows access to secrets. This secret can be a decryption key for decrypting a portion of memory, such as the portion of the hard disk where the boot manager is stored. As shown in step 602, this key can also be retrieved by the boot block component. By requesting the boot block to generate the correct expected measure for the boot manager, the first layer of security is provided, and if an incorrect value is given, the TPM Access to the keys needed to decrypt can be denied.

  If the correct expected value is given, the encryption key can be retrieved and then the boot manager component can be decrypted in step 603 using the encryption key. The boot block may then be configured 604 to permanently discard the “boot access only” key used to decrypt the boot manager. If the boot manager or the next component to be loaded is corrupted, the key cannot be accessed and thus the data that can be accessed is severely limited, so the boot access key is discarded before loading the boot manager This adds a layer of security. This is especially true when the computer hard disk is almost fully encrypted, as considered for the various embodiments of the present invention.

  The boot manager component can then be measured 605, such as calculating the hash value of the component. Measurements can be stored 606 in another PCR, such as PCR13. As shown in step 607, the values stored in PCR 10 and PCR 13 can be compared to determine if they match. If not, the conclusion can be reached that the boot manager has been changed and may contain broken or malicious code. Recall that we have not yet migrated to running the boot manager component, so we cannot yet do any harm. If the boot manager is broken, the boot block can take appropriate security measures. Thus, booting a computer can be contingent upon successful decoding and measurement of critical software components such as a boot manager.

  Referring to FIGS. 7 and 8, exemplary systems and methods are shown that can be used to conceal secrets used later during boot from a process that controls computing resources. The process shown in FIGS. 7 and 8 is particularly useful in situations where multiple disk partitions currently exist on a computer hard drive, but has other advantages that are understood to be useful in various settings. is doing. One advantage of the processes shown in FIGS. 7 and 8 is that they can be used to restrict access by a software component to a single partition. Components at the early stages of boot often require access to all disk partitions, but later stages and post-boot components can be limited to a single partition. 7 and 8 illustrate exemplary systems and methods for ensuring such limitations.

  FIG. 7 provides the settings for the process shown in FIG. On the left side of the drawing, a plurality of disk partitions are shown, including partition A 700, partition B 702, and partition C 704. As will be appreciated by those skilled in the art, each partition is generally complete except for information required in the early stages of boot, stored in reserved partitions such as 701, 703, and 705. Can be encrypted. Software components including a boot block 706, a boot manager 707, and an operating system (OS) loader 708 that can be read sequentially as described with reference to FIG. Along. Multiple PCRs are shown in the middle of FIG. 7, including PCRx709, PCRy710, time 1 PCRz711, and time2 PCRz712. PCRs are generally identified by numbers rather than letters, although it should be understood that the present invention is not limited to the particular PCR used, although some embodiments may use the PCR illustrated in FIG. Letters are used here for emphasis. The PCR of FIG. 7 performs the function described with reference to FIG. 5 (the value can be placed inside), trusts the TPM 713 to indicate whether this value is correct, and / or the correct value. Can be granted access to the secret when is entered.

  Prior to a more detailed description of the embodiment reflected in FIG. 8, a general concept can be formulated with reference to FIG. In order to gain access to a key or boot-only secret such as BLOB 714 through TPM 713, one or more PCR first values 711, such as the value of PCRz at time 1, is required. A boot-only key or BLOB 714 is useful for decrypting information from multiple partitions, as required in the early stages of computer booting. In order to gain access to a volume-bound key or BLOB 715, one or more second PCR values such as PCRz 712 at time 2 are required. A volume restriction key or BLOB is useful only for a subset of partitions, such as only to decrypt data from partition A700. Thus, downstream software components can be used for boot components by using different values of the same PCR at different times and adjusting key or BLOB access to the appropriate key for these multiple values Access to sensitive information. In order to boot properly, the volume restriction key or BLOB 715 must be accessed, which ensures that the boot-only key or BLOB 714 is no longer accessible. Additional advantages of this system will be apparent to those skilled in the art, particularly in combination with the system and method shown in FIG.

  Referring to FIG. 8, various embodiments for implementing a system such as that schematically illustrated in FIG. 7 are shown. Thus, in step 800, the boot manager component can be loaded. In a system incorporating the technique of FIG. 6, the boot manager can be loaded according to the process shown therein. For example, in step 801, the boot manager hash value can be measured and placed in the PCR 10. Second, as is common for the use of TPM, not only all previous measurements, but also PCR [11] and [12], for example, which have not yet been read in with measurements, so typically Based on the values of PCR [y] and [z] that hold an initial value that is zero, the boot access dedicated key can be retrieved from the TPM. Therefore, the secret can be extracted in step 802 based on the initial values of PCR [y] and [z].

  Still referring to FIG. 8, in steps 803 and 804, the OS loader can be loaded into memory and measured by the boot manager. The OS loader hash value can be placed in PCR [y] 805. This change to PCR [y] will effectively revoke future access to the boot access-only secret, so if the secret is discarded by the boot manager, the secret will be lost to downstream components. Please be careful. PCR [y] can then be compared 806 to the value stored in the boot access private secret. For example, if the boot access private secret is a BLOB, the PCR value can be stored with the BLOB. If the comparison is successful, the volume restriction key can be extracted from the BLOB dedicated to boot access 807. A volume restriction key can be measured and placed in PCR [z] 808. The TPM can be configured 809 to allow access to the volume restricted secret based on the new PCR value through PCR [z]. Therefore, by acquiring the volume restriction BLOB in step 809, the difficulty of accessing the boot access dedicated BLOB can be adjusted. In the practice of the present invention utilizing this technique, all subsequent processes can be effectively restricted to a subset of partitions associated with a volume restriction key or BLOB.

Exemplary Boot Verification Process for Protecting System Data Embodiments of the present invention can provide a boot verification process that can operate and be configured with user commands through a user interface (UI). . Thus, a program such as a control panel applet can be used to enable a UI that allows a user to enable the operation of the boot protection process according to the present invention. If the machine user has not acquired ownership of the machine's TPM, the UI may first offer an option to acquire or cancel ownership. Similar options can be presented that require the user to select a particular boot partition. If the protected boot is configured to work only with a specific file system, such as New Technology File System (NTFS), the user can select a boot partition to use that file system. Can be requested.

  When protected boot is enabled by the UI, the automatic process will regenerate the top-level secret to be secured, if possible, and then the expected PCR register required for secret disclosure. It can be guaranteed to be concealed in the value. Preferred embodiments can utilize PCR [4], PCR [8] up to PCR [15] for this operation. You can delegate the disclosure operation to the password and store it in a publicly visible location. Therefore, the selected password can be different from that used for the concealment operation. In order to support this operation, TCG® 1.2 TPM is preferred. This process variant that can provide higher security allows more PCRs to be specified, allowing the machine owner to specify a password for disclosure and enter it early in the boot process. It becomes possible.

  In a conventional PC or AT computer (PCAT) system, i.e., an x86 based system using a prior art BIOS, expected using MBR boot sector, NTFS boot sector, NTFS boot block, and boot manager PCR value can be determined. Further details about expected PCR values are described below in conjunction with an exemplary boot sequence. For an extended firmware interface (EFI) system, the associated files in the EFIU system partition (ESP) are measured. For variants of the present invention that include boot volume encryption, the disk encryption key can be concealed from the PCR for the initial boot up to that point, including the NTFS boot block.

  To help with recovery scenarios, recovery through CDROM, and recovery through a specific recovery partition if such a partition exists, and recovery through a second authentication method such as removable media and / or password Including other copies of the above secrets can be kept secret.

An exemplary boot process for the PCAT system is provided below. The process displayed here can also be understood with reference to FIGS.
• As required by the TCG® 1.2 specification, the read-only portion of the ROM responsible for measuring BIOS and placing it in PCR [0] can be implemented.
• Measure BIOS configuration parameters and place in PCR [1].
• Measure option ROM and place it in PCR [2].
• Measure option ROM parameters and place in PCR [3].
• Measure MBR and place in PCR [4].
• Measure the partition table and place it in PCR [5].
• After measuring the MBR, the BIOS forwards execution to the MBR.
The MBR reads the NTFS boot sector of the active partition, measures it and places it in PCR [8]. The MBR then transfers execution to this boot sector.
The boot sector reads the boot block into memory (generally 8K). The boot block is measured and placed in PCR [9] (excluding encryption information). If the volume is encrypted, the encryption information is disclosed at this point and is used to decrypt any future sectors read from the disk.
The boot manager is read from disk into memory. Measure the boot manager and put it into PCR [10]. Transfer execution to the boot manager. (One variation as described above is to store the expected PCR [10] measurement in secret data and use it to verify that the correct boot manager was measured. it can.)
The boot manager measures important data and puts it into PCR [11]. Important data can include information that can affect security, for example, whether the debugger is about to be enabled. In some embodiments, PCR [11] cannot operate according to this information until it is extended with information.
The boot manager selects the OS loader and places it in memory, measures it, puts it in PCR [12], and transfers execution to the PCR [12].
The OS loader measures important data and puts it in PCR [13].
The OS loader uses PCR [4], PCR [8] to [13], and optionally any additional PCR to disclose the secret used by the OS loader.
The OS loader forwards “Code Integrity” for further verification of the system.
Code integrity verifies each future binary read by systems such as phase-0 drivers, NTKRNL, and HAL.
NTKRNL starts initial system processes including LSASS and WinLogin.
LSASS discloses SYSKEY using PCR [4], PCR [8] to [13], and optionally any additional PCR. If the disclosure fails, the LSASS determines the cause, suggests corrective action, and / or requests recovery information, and obtains the secret in a secondary manner.
All code that accesses the decrypted boot volume will disclose the boot volume decryption secret using PCR [4], PCR [8] and [9], and any additional designated PCR To do.

In the EFI system, several variants to the above process are advantageous. For example, instead of measuring MBR and transferring execution to it, the following actions can be taken. That is,
• Measure ROM-based drivers in addition to those in option ROM and place in PCR [2].
• Measure disk-based drivers and modules, including the boot manager, into PCR [4].
Any EFI driver that understands NTFS has the additional ability to disclose the boot volume decryption secret.

  The above process and variations thereof can be used for purposes beyond the scope of standard computer boot. In particular, two additional purposes are envisioned, but additional uses of the invention are also possible and the invention is not limited to any particular setting or purpose. First, the above process can be extended to include hibernation file protection. Second, the above process can be extended to include boot volume and other volume protection required for operating system operation.

  For hibernation file protection, this can be accomplished by storing the hibernation file encryption and decryption keys in an available secret. The encryption key and decryption key can be a single symmetric key or an asymmetric key used to seal another symmetric key. When the machine goes to hibernation, the hibernation file can be encrypted. The hibernation file cannot be decrypted unless the machine boots through the verified boot code path, so any secret stored in the hibernation file is maintained. If the machine boots through a verified code path, the hibernation file is decrypted by the verified code and execution resumes with a well-defined execution path, restoring the security of the execution environment.

  Boot volume or other volume protection required for operating system operation may also be achieved. In this case, all boot volumes can be encrypted and / or include an overall integrity check. The key required for decryption is only available for the verified boot code, which can then be used to provide additional code and data needed to resume system boot. Decipher. The key required to update the disk integrity information is also only available for verified boot code. A system that includes an overall integrity check may only select verified integrity code and data for further operations once it is guaranteed that the system is executing the verified code. it can. Since only verified code can disclose these usable bits, an attacker cannot deceive such a system and believe that its integrity is valid.

Exemplary System and Method for Repairing and Upgrading a Protected Boot Process Embodiments of the present invention provide a process for diagnosing, repairing, and upgrading a system and method for securely booting a computer. Can be incorporated. For this purpose, the first observation for diagnosing problems within the boot process is that in the above-described protected boot process, the process that discloses the secret determines whether the measurement is correct. It is a point of providing the means. Therefore, there is a possibility that a secret indicating two states, that of the code to be measured, is disclosed and only the verified code is executed, or that the secret is not disclosed and unverified code is executed. One of the states indicating that there exists. For diagnosis, it is possible to determine what has failed by examining the logs created by the TCG compliant BIOS. This information can then be used to diagnose the problem and feed back more information when the error was accidental rather than intentional.

  The protected boot process described above relies on system self-verification through the use of TPM. In some embodiments, such a system may appear invalid when it is actually still valid. When the system appears invalid, in various embodiments of the present invention, there are two resolution paths that can be enabled, either or both, ie, the first is from examining the log. The obtained information can be used to return the system to a state where it can be considered valid, and the second can allow the user to authenticate that the system should be considered valid.

  To return the system to a state where it can be considered valid, the log information can be used to diagnose why the TPM considered the measurement invalid. Some changed code can be restored to its original state. Alternatively, if the user boots in an unusual manner, such as by attempting a network boot before booting off the system disk, it will reboot the computer and attempt to boot in the expected manner.

  There are a number of additional features that can be incorporated into the product to supplement the embodiment that returns the system to a valid state. For example, if the hardware on the machine is broken and the disk is otherwise the same seed but migrated to the machine, the TPM secret key may be different. In this case, the user can be authenticated instead of the machine. A number of mechanisms can do what is called secondary authentication. The certificate for this need not be easily accessible, for example, it can require that the phone be called to re-enable the machine. The secondary authentication provides the same secret that is decrypted by the primary TPM method and can be obtained in another way. Such an embodiment can provide stronger security compared to using the same method as the primary authentication method. For example, the machine password does not need to be easy to remember and can be generated entirely randomly. When a machine requires authentication by this secondary method, the machine user calls the IT department. The IT department verifies the identity of the caller using an optimal system and reads the password to the caller. When a password is entered, the migration mechanism described above can be used in this scenario to re-secret the secret to a new TPM PCR value. In addition, such a system can use a password system that yields a password that can only be used once, and a secret that is again hidden in the new password for the secondary authentication mechanism requires a new telephone contact.

  Embodiments of systems and methods for securely booting a computer can be configured for easy upgrade. Although the code monitored by embodiments of the present invention is rarely changed, it is inevitable that one of these code modules will eventually be changed. Furthermore, the secret used for the secure boot process can be kept secret to the TPM when the system is first configured or after recovery as described above.

  The first method of upgrading one or more boot components can take advantage of migrations that are possible after recovery or code modification and store them in temporary storage until a TPM PCR value is determined. Can do. In many embodiments, this does not require a reboot, as the PCR value is known at the current boot. However, if the code module is changed, rebooting ensures that the new code module is measured and the value is stored in the TPM PCR.

  In a controlled code modification environment, a second method of upgrading one or more components can be used. In this case, an expected PCR value for new code correction is determined in advance, and the secret can be concealed in the expected PCR value before the system is rebooted.

The running system has the following non-limiting options:
Before the change, for example, the service pack can know that it changes the OS loader.
• Immediately after the change, eg after the disc has been formatted.
• After detecting a change in a verified system, for example at shutdown, the system can notify that a component has been legally modified and can perform the migration silently.
・ As part of recovery. For example, when the system is started, the system can determine whether recovery has been performed and perform migration, so that a recovery mechanism is not required after the next boot.
The above migration can be performed according to one or more of the following:

  Yet another system for maintaining a secure boot process can provide a number of different keys created outside of the TPM. Each of these keys can use the same RSA keying material, but the use of each key must be bound to a different set of PCRs and / or passwords. In fact, these additional keys may not be bound to anything at all. In such embodiments, at least one BLOB can also be associated with each disk volume (eg, partition) that is not bound to anything at all. Each key can be used from a different boot component to ensure BLOB privacy. Password-type keys can be used for recovery and RSA keying material can be deposited.

  This approach is only slightly different from the secure boot process described above, but it has significant advantages in terms of maintenance and service. That is, due to the fact that RSA keying material is generated outside of the TPM and is the same in every key, this RSA material is much larger for a large number of users, such as a business unit employee or an entire organization employee. Can be used on a scale. As a result, a master key can be created that allows any machine in the organization to start and service. Since the key is still protected by each TPM's SRK, it can still be considered secure. However, in this embodiment, a central unit such as an information technology (IT) department does not need to store one key per machine, but rather one key per logical group. Also, in order to store a large number of keys across a large number of BLOBs, the central part only needs slightly less storage space in the boot block.

  Finally, in the embodiment described above, the administrator can now push down policies and new RSA keys, so keys are changed frequently on each machine. This reduces machine maintenance costs.

Permanent destruction of data access using full volume encryption and protected boot The by-product of the secure boot process described above is full volume encryption, i.e. encryption of almost all data in a partition. It is the point that it can support efficiently and effectively. This can destroy the secret and thereby reduce the effort required to destroy the important information needed to access the data on the computer. This effective data destruction is useful in certain settings, especially when the destruction of sensitive data is desired, and more specifically when such data is quickly destroyed.

  By removing the secrets required to operate a computer that implements the present invention, the computer becomes unusable and permanently accessible to data on the computer without having to reinstall the software. Can be prevented. To achieve this, the secret stored inside the TPM can be reset. This can be done by changing the owner of the TPM. Secrets concealed by the TPM are no longer valid. It is also necessary to destroy the secondary recovery mechanism. However, if the recovery mechanism is remote from the site, a method can be provided that temporarily disables the machine for a short period of time before the mechanism is destroyed and then recovers the machine.

  When both the secret stored in the TPM and any of the recovery mechanisms are changed, the machine content, both code and data, becomes unobtainable. This achieves a very fast cleaning of the machine. One advantage of such effective security erasure is that it makes resale of machines more realistic.

FIG. 7 illustrates a computing environment suitable for implementing software and / or hardware technology associated with the present invention. FIG. 2 provides an extension of the basic computing environment of FIG. 1 to emphasize that modern computing technology can be implemented across multiple networked devices. FIG. 1 illustrates a computing platform that utilizes a trusted platform module (TPM). FIG. 4 illustrates an exemplary boot process in which multiple software components measure the next process before moving to the next process. FIG. 2 illustrates a general technique for using a hardware security module (HSM), such as a TPM, that ensures the integrity of the next software or process before enabling execution of the next component. . 1 illustrates a system and method for ensuring that the boot process cannot proceed unless the measurements of data used in the process are verified by the TPM. FIG. 6 illustrates an example of the system and method shown in FIG. 5a, where successfully booting a computer is associated with successfully decoding and measuring an exemplary component or boot manager. FIG. 4 illustrates an architectural operation for providing a boot component to access a resource for a period of time and then disabling access to the resource before starting the operating system. FIG. 8 is a flow chart for exemplary steps performed in an architecture such as FIG.

Explanation of symbols

100: Computing system environment 121: Computer 130: Wide area network 135: Local area network 300: CPU
301, 503, 504, 713: TPM
302: Secret 303, 304, 502: PCR
307: Log

Claims (20)

A computer security comprising a hardware security module (HSM) that includes a recorded value, compares the submitted value with the recorded value, and discloses a secret if the submitted value is correct A computer- readable storage medium having instructions for a complete boot process,
An instruction for submitting at least one value to the HSM, wherein the HSM discloses a secret if the value is correct;
An instruction to retrieve the secret,
An instruction for decrypting data using information that can be accessed as a result of extracting the secret, the instruction generating data decrypted by execution of the instruction for decryption;
Instructions for at least part of a computer boot process that cannot complete a normal boot without the decrypted data;
A computer- readable storage medium comprising: The computer- readable storage of claim 1, wherein the HSM is a trusted platform module (TPM) and at least one value is placed in at least one platform configuration register (PCR). media. The computer- readable storage medium of claim 1, wherein the decrypted data includes software components used in a computer boot process. The computer- readable storage of claim 1, wherein the decrypted data includes information required by software components used in the computer boot process to continue the computer process. media. The computer- readable storage medium of claim 1, wherein the decrypted data includes information required to access data stored on the computer- readable storage medium. The computer- readable storage medium of claim 1, further comprising instructions for removing the secret from memory. A computer having a hardware security module (HSM) that includes a recorded value, compares the submitted value with the recorded value, and discloses a secret if the submitted value is correct, the computer comprising: The computer is also
Means for submitting at least one value to the HSM, wherein the HSM discloses a secret if the value is correct;
A means to retrieve the secret;
Means for decrypting data using information that is accessible as a result of retrieving the secret, the means for generating data decrypted by the operation of the means for decrypting;
Means including at least part of a computer boot process that cannot complete a normal boot without the decrypted data;
A computer comprising:   The computer of claim 7, wherein the HSM is a trusted platform module (TPM) and at least one value is placed in a platform configuration register (PCR).   The computer of claim 7, wherein the decrypted data includes software components used in the computer boot process.   The computer of claim 7, wherein the decrypted data includes information required by software components used in the computer boot process to continue the computer process. The decrypted data is a computer according to claim 7, characterized in that it comprises the information needed to access the data stored on a computer readable storage medium.   The computer of claim 7, further comprising means for removing the secret from memory. A plurality of partitions and a hardware security module (HSM) that includes a recorded value, compares the submitted value with the recorded value, and discloses a secret if the submitted value is correct; A computer- readable storage medium having instructions for a secure boot process on the computer having the computer- readable storage medium,
An instruction to submit at least one value to the HSM, wherein the HSM can disclose a secret if the value is correct;
An instruction to retrieve the first secret;
Instructions for removing the first secret from the storage location;
An instruction for submitting at least one second value to the HSM, wherein the HSM can disclose a second secret instead of the first secret if the second value is correct When,
A computer- readable storage medium comprising: The HSM is a trusted platform module (TPM), wherein at least one value and the at least one second value are placed in a platform configuration register (PCR). Computer- readable storage media. The computer of claim 13, further comprising instructions for at least a portion of a computer boot process, the computer boot process being unable to complete a normal boot without the first secret. A readable storage medium. Almost all to access the data, computer-readable of claim 13, wherein the second secret is required that is stored on at least one partition of a computer readable storage medium Storage media. The computer- readable storage medium of claim 13, wherein the first value comprises a hash value of a software component used in a computer boot process. The computer- readable storage medium according to claim 13, wherein the second value includes a hash value of a decryption key. The computer- readable storage medium of claim 13, wherein at least one of the first secret and the second secret is a binary large object (BLOB). The computer- readable storage medium of claim 13, wherein at least one of the first secret and the second secret is a decryption key.

Images