HK1181146B - Protected device management - Google Patents

Description

Protected device management

Copyright notice

The material contained herein is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the patent and trademark office patent files or records, but otherwise reserves all copyright rights whatsoever.

Technical Field

The present disclosure relates generally to the management of devices protected by encryption, user authentication, and password protection schemes.

Background

Corporate data is becoming increasingly mobile, decentralized, and rich. Data is typically retrieved from physically secure facilities to accommodate workers who travel or have flexible working habits. The data is also geographically dispersed as the business interests of companies bring them to other cities, states and countries. Data is rich in the rate of generation and the multimedia format in which they are presented. All of these forces have driven the development of new storage media, higher bandwidth subsystems and network-connected storage devices that require data protection both during transport and at rest.

Static Data (DAR) encryption techniques prevent unauthorized use of data stored on lost or stolen storage devices, thereby preventing the dissemination of such data over the internet or other networks. DAR encryption serves as an automatic and fast response mechanism to prevent the inevitable loss and theft of storage devices into the loss and theft of data stored on those devices.

One of the challenges in protecting data stored on various storage devices associated with a computing platform is that encryption techniques and key management policies differ depending on the entity performing the encryption. The storage hardware may have built-in encryption capabilities that are unique to the storage hardware vendor, requiring the use of the storage hardware vendor's tools to access the data. Software-based encryption requires a different key generation and management service than hardware-based encryption and therefore requires the use of software vendor's tools to access the software-encrypted data. Thus, key recovery and data migration plans when theft or loss occurs require the use of tools from multiple different vendors to protect and/or recover all data associated with a computing platform.

Another challenge in protecting data stored on a storage device is that the storage device itself may be protected using a cryptographic protection scheme. For example, according to the Advanced Technology Attachment (ATA) specification, disk locking is a built-in security feature for hard disk drives. The ATA specification specifies that a disc has two passwords: a user password and a master password. A disc can be locked in two modes: a high security mode or a maximum security mode. In the high SECURITY mode, the disc can be unlocked by a user password or a master password using a "SECURITY UNLOCK DEVICE" ATA command. There is an attempt limit, typically set to 5, after which the power source must be restarted or the disk reset hard before unlocking can be attempted again. Also, in the high SECURITY mode, SECURITY ERASE UNIT command may be used with the user password or the main password.

In the maximum security mode, the disc cannot be unlocked without a user password. The only way to bring the disk back to an available state is to issue a secure ERASE PREPARE (secure erase ready) command first, followed by a secure erase request command. In maximum SECURITY mode, the SECURITY ERASE UNIT command requires a user password and will completely ERASE all data on the disc. Thus, if the disc is password protected, set to maximum security mode, and the user password is unknown, the data on the disc is not recoverable.

Yet another challenge in protecting data stored on storage devices associated with a computing platform is that the platform may need to authenticate user credentials before allowing access to the data on the associated storage devices. For example, some computing platforms utilize Kerberos user authentication for protection. Kerberos utilizes the symmetric needlem-scheduler protocol as its basis. It makes use of a trusted third party called the Key Distribution Center (KDC), which consists of two logically independent parts: an Authentication Server (AS) and a ticket licensing server (TGS). Kerberos works on the basis of "tickets" that are used to validate the identity of a user.

The KDC maintains a database of secret keys; each entity on the network (whether a client or server) shares a secret key known only to itself and the KDC. Knowledge of this key is used to prove the identity of the entity. For communications between two entities, the KDC generates a session key that they can use to secure their interactions. The security of the protocol relies heavily on participants who keep a loose synchronization time and short-term authenticity assertions called Kerberos tickets.

Under the Kerberos protocol, the client authenticates itself to the authentication server and receives tickets (all tickets are time-stamped). The client then contacts the ticket licensing server, which proves its identity and requires service by using the ticket. If the client is eligible for service, the ticket licensing server sends another ticket to the client. The client then contacts the service server, using the ticket, to verify that it has been approved to receive the service.

Drawings

FIG. 1 is a block diagram of a system configured to manage devices protected by encryption, user identity authentication, and password protection schemes, according to one embodiment of the invention.

FIG. 2 illustrates further details of the system of FIG. 1 in managing protected devices according to one embodiment of the present invention.

Fig. 3 is a flow chart of a method performed when resetting (reset) a system having devices protected by encryption, user identity authentication, and password protection schemes according to one embodiment of the invention.

Fig. 4 is a flow diagram of a method performed upon receiving a command to unlock a device protected by encryption, user identity authentication, and password protection schemes, according to one embodiment of the invention.

FIG. 5A illustrates further details of the system of FIG. 1 in enabling devices protected by encryption, user identity authentication, and password protection schemes to be dynamically attached and user authentication credentials to be dynamically reconfirmed without rebooting in accordance with one embodiment of the present invention.

FIG. 5B is a flow chart of a method performed by the system of FIG. 5A in recognizing a hot plug event of a device.

FIG. 6 illustrates further details of the system of FIG. 1 in managing protected devices according to one embodiment of the present invention.

FIG. 7 is a flow diagram of a method performed upon detection of a potentially auditable event occurring within a secure partition of a system according to one embodiment of the invention.

FIG. 8 illustrates a virtual machine environment for implementing secure partitioning to manage actions such as protecting a device with encryption, user authentication, and password protection schemes, according to one embodiment of the invention.

Detailed Description

Embodiments of the present invention may provide methods, apparatus, systems, and computer program products for managing a system having devices protected by encryption, user identity authentication, and password protection schemes.

Reference in the specification to "one embodiment" or "an embodiment" of the present invention means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment," "according to one embodiment," and the like in various places throughout this specification are not necessarily all referring to the same embodiment.

For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that embodiments of the present invention may be practiced without the specific details presented herein. In addition, well-known features may be omitted or simplified in order not to obscure the present invention. Various examples are given throughout the description. They are merely illustrative of specific embodiments of the invention. The scope of the invention is not limited to the examples given.

In one embodiment, protected device management is provided within a secure partition that provides an isolated and controlled environment. The secure partition may receive a command from the trusted management application to perform a management operation. The secure partition ensures that it is verified that the command to manage the protected device originates from an authenticated source. The trusted management application may be remote from the system and may communicate with the secure partition via a secure communication channel.

The isolated and secure environment of the protected device manager may include a variety of different types of partitions, including fully separate hardware partitions (e.g., utilizing Intel corporation's manageability engines ("ME"), active management technology ("AMT"), platform resource layer ("PRL"), and/or other comparable or similar technologies) and/or virtualized partitions (e.g., virtual machines in Intel corporation's virtualization technology ("VT") scheme). One of ordinary skill in the art will appreciate that the ME, AMT, and PRL techniques may also be implemented using a virtualized host (as described in further detail below with reference to FIG. 8).

In one embodiment, the protected device manager executes in a secure partition that is isolated from the host operating system of the system. The secure partition may receive a request to unlock an encryption device coupled to the system. The secure partition receives the request via a secure communication channel established between the trusted remote console and the secure partition. The secure partition unlocks the cryptographic device in response to the request without involvement of the host operating system.

The secure partition may receive a token from the trusted remote console and utilize the token to unlock a key used to encrypt blocks of the encryption device. The secure partition may obtain the key from a secure storage area of the cryptographic device, where the secure storage area is hidden from the host operating system. The secure partition may confirm that the request originated from the trusted remote console before unlocking the encrypted device. The secure partition may perform the management operation after unlocking the cryptographic device, wherein the request further specifies the management operation to be performed, and boot the host operating system after performing the management operation. When a host operating system of the system fails, unlocking of the encryption device may be performed without involvement of a system user.

FIG. 1 illustrates a system configured to manage devices protected by encryption, user identity authentication, and password protection schemes according to one embodiment of the invention. Platform 100 includes a processor 110 connected to a chipset/secure partition 120 via a Desktop Management Interface (DMI) 111 a. Chipset/secure partition 120 includes a Manageability Engine (ME) 130 for managing the configuration and operation of platform 100, ME 130 may be implemented as a microprocessor. In one embodiment, Manageability Engine (ME) 130 collects audit events, authenticates users, controls access to peripheral devices, manages encryption keys to protect data stored on storage devices of platform 100, and interfaces with management console 166 via network controller 160. Using management console 166, Manageability Engine (ME) 130 maintains compliance with enterprise-wide policies for configuration and management of platforms, such as platform 100. Manageability Engine (ME) 130 is connected to processor 110 via Host Embedded Controller Interface (HECI) 111 b.

Virtualization Engine Controller Interface (VECI) 111c connects processor 110 to I/O command decode module 140 of chipset/secure partition 120. In one embodiment, I/O command decode module 140 is a general purpose controller configured with specialized firmware to perform storage command decoding and other accelerated operations. The functionality of the I/O command decoding module 140 may also be implemented entirely in dedicated hardware. I/O command decode module 140 provides management functionality to protect data written to storage devices associated with platform 100. For example, the I/O command decode module 140 may interact with an encryption engine 150 for encrypting the storage device, protecting metadata for protecting the storage device, intercepting and processing hardware interrupts associated with the storage device, and facilitating management operations on the storage device.

Manageability Engine (ME) 130 controls the behavior of I/O command decode module 140 and encryption engine 150 by configuring policies and encryption keys. The operation of Manageability Engine (ME) 130, I/O command decode module 140, and encryption engine 150 will be described in further detail below.

Platform 100 also includes memory devices such as Dynamic Random Access Memory (DRAM) 114, Static Random Access Memory (SRAM) 122 within chipset/secure partition 120, and flash memory 190. When platform 100 is fully powered, a portion of DRAM 114, referred to as the Upper Memory Area (UMA), ME-UMA 116 is available for use by Manageability Engine (ME) 130. In general, host operating system 115 of platform 100 cannot access ME-UMA 116 because of the presence of a memory isolation mechanism configured through the Basic Input Output System (BIOS). This memory isolation mechanism locks access to ME-UMA memory 116 before the host operating system runs. By isolating the portion of DRAM 114 used by manageability engine 130 from the host operating system, the integrity of manageability engine 130 is protected from attacks by viruses or other malware that may infect host operating system 115.

Flash memory 190 contains firmware for initializing platform 100. The initialization firmware includes BIOS firmware 192, network controller firmware 194 for configuring network controller 160, and chipset firmware 196 for configuring chipset/secure partition 120. The integrity of Manageability Engine (ME) 130 and chipset firmware 196 of I/O command decode module 140 is ensured by the digital signature before the digital signature is stored on flash memory 190. Data (e.g., user authentication information) for use by Manageability Engine (ME) 130 may be encrypted by encryption firmware within Manageability Engine (ME) 130 and stored within data region 198 of flash memory 190.

The embodiment of platform 100 shown in FIG. 1 also includes a Universal Serial Bus (USB) controller 175 connected to USB device 177. USB devices may include pointing devices (e.g., a mouse), keyboards, digital cameras, printers, personal media players, flash drives, and external hard drives. The USB specification enables devices to be installed and removed without opening the computer chassis (hot-swapping) or rebooting the computer, making it useful for mobile peripherals, including various kinds of drives. Originally conceived and still used today for optical storage devices (CD-RW drives, DVD drives, etc.), several manufacturers offer an empty case of external portable USB hard drives or disk drives with comparable performance to internal drives, limited by the current number and type of USB devices attached and the upper limit of the USB interface (in fact, about 40MiB/s for USB 2.0, and potentially 400 MiB/s or more for USB 3.0). These external drives typically contain a "translation device" that bridges between the drive's interface (IDE, ATA, SATA, PATA, ATAPI, or even SCSI) to the USB interface port. Functionally, the driver appears to the user as an internal driver. Other competing standards for external drive connectivity include eSATA, ExpressCard (now version 2.0), and FireWire (IEEE 1394).

The embodiment of platform 100 shown in FIG. 1 also includes different types of storage accessible via I/O controller 170, including non-volatile memory storage 172 accessible via storage interface 171 and Serial Advanced Technology Attachment (SATA) storage 180 accessible via storage interface 181. Storage interface 171 may be implemented as a non-volatile memory Host Controller Interface (HCI) for non-volatile memory (NVM), while storage interface 181 may be implemented as an Advanced HCI (AHCI) interface for Serial Advanced Technology Attachment (SATA) storage 180. I/O controller 170 includes NVM and SATA controller functionality.

Data stored on storage devices 172 and 180 may be encrypted by encryption engine 150 of chipset/secure partition 120. SATA storage device 180 serves as an example of a device for chipset encryption and also includes a reserved area for storing metadata 182, metadata 182 including at least one Device Encryption Key (DEK) 184 of storage device 180 and other metadata for use by Manageability Engine (ME) 130. During processing of I/O commands by I/O command decode module 140 and I/O controller 170, metadata 182 is protected from overwriting by applications running on processor 110.

In one embodiment, Manageability Engine (ME) 130 inserts a Device Encryption Key (DEK) (such as DEK 184) associated with a storage device involved in an input/output operation into a memory register associated with encryption engine 150 prior to performing encryption or decryption of data by encryption engine 150 of chipset/secure partition 120. If a physical storage device is logically divided into multiple different logical devices or partitions, each logical device or partition may have its own respective Device Encryption Key (DEK), and each of those DEKs may be inserted into a respective memory register of encryption engine 150.

In one embodiment, Manageability Engine (ME) 130 manages encryption of all data associated with platform 100, including encryption performed by encryption engine 150 within chipset/secure partition 120 and data encryption not performed by the chipset, but rather by software running on processor 110 or by the storage hardware itself. One of the services provided by Manageability Engine (ME) 130 is to manage encryption keys in the common framework and user interfaces, independent of the components of platform 100 performing the data encryption. Further details regarding the framework of Chipset/secure partition 120 and Manageability Engine (ME) 130 and the operation in managing data encryption are provided in patent application 12/319210 entitled "Enforing Use of Chipset Key management services for Encrypted Storage Devices" by inventor Ned Smith, which is hereby incorporated by reference in its entirety.

FIG. 2 shows further details of Manageability Engine (ME) 130 and I/O command decode module 140 components of chipset/secure partition 120 in FIG. 1, according to one embodiment of the invention. Within chipset/secure partition 120, Manageability Engine (ME) 130 includes ME kernel 231, ME public services 233, protected device manager 235, security/key management firmware 237, and identity management firmware 239. Each of these components will be discussed in further detail below.

ME kernel 231 provides basic functionality, including memory usage of SRAM 122 as well as portions of DRAM 112 (e.g., ME-UMA 114), persistent data storage within flash memory 190, and access control. The ME kernel 231 controls the operation of the I/O command decode module 140 and the encryption engine 150.

ME public services 233 include services commonly required by different firmware modules, including security services, networking services, and provisioning services. Security services provided by ME public service 233 generally include: user authentication consisting of HTTP digest and Kerberos authentication; domain name authorization using microsoft active directory and/or other services; a clock synchronization service for synchronizing the client and server clocks; and a security audit service.

Networking services provided by ME public services 233 include the transport control protocol/Internet protocol (TCP/IP) stack, Transport Layer Security (TLS), Hypertext transfer protocol (HTTP), Simple Object Access Protocol (SOAP), web services manageability (WS-MAN), and host-based TLS interfaces known as Local Manageability Services (LMS).

The provisioning services provided by ME public services 233 are used with management console 166 in fig. 1 to provision enterprise software to platform 100. These provisioning services support two deployment modes: zero touch and one touch. In zero touch mode, the deployment certificate anchor key is stored in a data storage area, such as data region 198 of flash memory 190 of FIG. 1, to allow the IT credential to be verified with a well-known certificate authority key and then be used to gain ownership of the platform. The one touch mode configures organization certificates, symmetric keys, and trusted hosts that can be used to remotely complete setup and deployment tasks.

Manageability engine 130 also includes out-of-band (OOB) communication module 230. OOB communication module 230 facilitates communication between components of platform 100 and corresponding components of management console 166 via network controller 160. The OOB communication module 230 establishes a secure OOB communication channel 168 between the chipset/secure partition 120 and the management console 166.

Manageability Engine (ME) 130 also includes identity management firmware 239. Identity management firmware 239 may compare the user's authentication information to user account metadata stored in, for example, data region 198 of flash memory 190. Identity management firmware 239 may also interact with security/key management firmware 237 of Manageability Engine (ME) 130 to confirm that the user's information is also stored in a container within a storage device, such as SATA storage device 180. This confirmation of a user's access to a particular storage device, such as SATA storage device 180, provides an additional layer of protection to data stored on SATA storage device 180.

Security/key management firmware 237 manages keys such as encryption keys created by encryption engine 150. Security/key management firmware 237 may also authenticate a user before allowing access to data stored on a storage device associated with platform 100. Security/key management firmware 237 manages and stores key management information in memory or storage associated with the platform (e.g., flash memory 190 or SATA storage device 180). The location where the key management information is stored depends on the available storage space and the amount of data to be stored, and the present invention is not limited to a particular configuration for storing the key management information. In one embodiment, security/key management firmware 237 encrypts key management information with a Platform Container Key (PCK) bound to platform 100.

The key management information managed by security/key management firmware 237 includes an encryption key, referred to as a Device Encryption Key (DEK) 184, generated by the chipset (i.e., by encryption engine 150 within chipset/secure partition 120) and stored in metadata 182.

Manageability Engine (ME) 130 is also shown to include protected device manager 235. In one embodiment, protected device manager 235 communicates with I/O command decode module 140 to provide a device password for unlocking a device, such as SATA storage device 180. The operation of protected device manager 235 will be described in further detail below with reference to fig. 3 and 4.

I/O command decode module 140 is shown to include I/O module kernel 241 and SATA virtualization firmware 243. The I/O module kernel 241 provides basic functionality to the I/O command decode module 140 and receives commands from the ME kernel 231. Although SATA virtualization firmware 243 is described as firmware with reference to this embodiment, the functionality of SATA virtualization firmware 243 may also be implemented as dedicated hardware. SATA virtualization firmware 243 is used to access SATA storage devices, such as SATA storage device 180, and enables Manageability Engine (ME) 130 to perform device management functions. For example, SATA virtualization firmware 243 enables protected devices to be accessed remotely by management console 166 without the involvement of host operating system 115 or other host software running on processor 110 by injecting SARA control packets into the I/O data stream. The control packet may be used to unlock SATA storage device 180, for example, via a command from management console 166.

SATA virtualization firmware 243 also serves to hide a range of linear block addresses on SATA storage device 180 from host operating system 115. This range of hidden linear block addresses hidden from host operating system access is referred to herein as a secure storage area, which is protected so that device metadata 182 may be stored on the drive. Device metadata 182 may include a device encryption key 184 that enables encryption and decryption of blocks of SATA storage device 180.

SATA virtualization firmware 243 may also intercept events detected by I/O controller 170, such as hot-plug interrupts generated when a new device is attached to platform 100. SATA virtualization firmware 243 can also monitor I/O flow to and from storage devices and detect events for auditing.

In one embodiment, SATA storage device 180 is secured with an encryption and password (e.g., an ATA password), which the user must enter to access the device. The password is used to unlock the native locking mechanism of SATA storage device 180. Encryption engine 150 is used to encrypt blocks of SATA storage device 180. The SATA Device Encryption Key (DEK) (e.g., DEK 184) is stored on the SATA device in a location that is hidden from the host operating system. First, the device is unlocked by using a password for the native locking mechanism, and then the DEK can be accessed to decrypt the encrypted block.

When platform 100 is reset, I/O command decode module 140 and Manageability Engine (ME) 130 cooperate to read device metadata, such as encryption keys and user authentication credentials, from the device and store the device metadata in secure storage, e.g., as device metadata 298 in flash memory 190 data area 198. In one embodiment, for each user that can be authenticated through management console 166, there is a token, such as token 1266A in FIG. 2, that is used to derive the wrapping key for the particular device. And the device wrapping key is used to wrap the encryption key for that particular device.

The user wrapping key and device wrapping key are used together to determine whether the user has access to a particular device, and the user wrapping key/device wrapping key pair is stored as device metadata 298 in data region 198 of flash memory 190. In contrast, device encryption keys, such as the DEK184, are stored on the storage device itself. When a device is to be accessed, a copy of token-1 is used to determine the appropriate user wrapping key/device wrapping key pair from device metadata 298. The device wrapping key in the key pair is used to decrypt the metadata 182 on the device, thereby exposing the device encryption key 184. When no user is present, or when the user cannot generate the required authentication credentials, a management operation is performed on the storage device using token-1.

In one embodiment, encryption engine 150 encrypts device metadata 182 with another device wrapping key derived from another token (referred to herein as token-2) stored on a USB device, such as USB device 177. USB device 177 is intended to be securely stored in a physical location remote from where a thief might access it. Token-2 is utilized to perform management operations on the storage device when no network connection is available for the remote management console 166 to connect to the storage device. USB device 177 contains token-2 in unencrypted plaintext form so that the holder of token-2 is implicitly authorized to perform management operations on the storage device. If token-2 is provided, a second set of user wrapping keys is derived using token-2 and a second set of user wrapping key/device wrapping key pairs is also stored in flash memory 190 as part of device metadata 298. Both token-1 and token-2 values are protected by a user authentication system, such as identity management firmware 239, so that only authorized users can expose the device encryption key.

In one embodiment, token-1266A is securely archived in a remote storage device 266 (or directory service) associated with management console 166 along with device 180 password 266B. Management console 166 utilizes device 180 password 266B and token-1266A to remotely unlock SATA device 180. The remote management console 166 provides the device 180 password 266B to the protected device manager 235 and the protected device manager 235 uses the device 180 password 266B to unlock the device. Protected device manager 235 provides token-1266A to security/key management firmware 237, which security/key management firmware 237 may utilize identity management firmware 239 to unwrap the user wrapping key. The user wrapping key is used to unwrap the device wrapping key, which is used to decrypt metadata 182 and thereby provide access to device encryption key 184, which encryption engine 150 may utilize to decrypt blocks of SATA storage device 180. The token-1266A is protected from network attacks by relying on a secure communication channel (e.g., OOB communication channel 168) between the management console 166 and the chipset/secure partition 120. The OOB communication channel 168 may be secured using, for example, Kerberos session keys.

Because data on SATA storage device 180 is encryptable, Device Encryption Key (DEK) 184 is stored in a location accessible to protected device manager 235 of Manageability Engine (ME) 130. By making the DEK available to protected device manager 235, SATA read/write requests via HECI/VECI interfaces 111b and 111c can be serviced even if the data on SATA storage device 180 is encrypted. Once protected device manager 235 has access to the password to unlock SATA storage device 180, protected device manager 235 can make a copy of the device wrapping key stored in device metadata 298. The device wrapping key may be used to unwrap the device encryption key contained in the device metadata of each SATA device attached to the platform.

Fig. 3 is a flow diagram of a method performed when resetting a system having devices protected by encryption, user identity authentication, and password protection schemes according to one embodiment of the invention. The method of fig. 3 will be described as being performed by components of the system of fig. 2, but the method is not limited to such an implementation. Once a system reset occurs, control proceeds to "ME protected device manager reads device metadata indirectly from SATA device through MECI via I/O command decode module" step 310. Manageability engine 130 protected device manager 235 obtains information about attached storage devices by reading device metadata from SATA devices, such as SATA storage device 180, at step 310. Because manageability engine 130 is not directly connected to storage devices, manageability engine 130 protected device manager 235 accesses device metadata indirectly through MECI 131 via I/O command decode module 140. Manageability engine 130 protected device manager 235 utilizes SATA virtualization firmware 243 to access device metadata stored on SATA devices such as SATA storage device 180. SATA virtualization firmware 243 exposes a storage interface to protected device manager 235 so that SATA storage device 180 appears as a block storage device for linear block addresses. SATA virtualization firmware 243 hides some linear block addresses from the host operating system and exposes them to protected device manager 235. SATA virtualization firmware 243 interacts with SATA storage device 180 using SATA I/O protocols.

From step 310 "ME protected device manager indirectly reads device metadata from SATA device through MECI via I/O command decode module", control proceeds to step 320 "I/O command decode module reads virtual drive definition metadata containing metadata descriptor information". In step 320, I/O command decode module 140 SATA virtualization firmware 243 reads virtual drive definition metadata that includes metadata descriptor information stored in metadata 182 (which is stored on SATA storage device 180). In one embodiment, SATA virtualization firmware 243 virtualizes storage devices so that multiple virtual drive partitions can be recognized. Each of these virtual drive partitions will be described in the virtual drive definition data. Included within the first virtual Hard Disk Drive (HDD) definition may be a conventional drive geometry element. For example, starting at Linear Block Address (LBA) zero, a Master Boot Record (MBR) may be stored, followed by drive data such as operating system files and user files. Some systems have hidden partitions available for use by the BIOS or other system facilities. The Host Protected Area (HPA) may be used to store emergency Recovery OS (ROS), multimedia tools, diagnostic tools, or other programs. A system implementing Redundant Array of Inexpensive Disks (RAID) may place RAID metadata at the end of a virtual drive. By placing RAID metadata at the end of the virtual drive, the RAID option ROM can easily locate the RAID metadata at system initialization.

In one embodiment, a single device encryption key, such as DEK184, spans each virtual HDD across the device, resulting in all virtual HDDs being encrypted with the same key. Virtual Drive Definition (VDD) data is placed at the end of the physical drive, for example at the last linear block address LBA-n. The VDD data contains drive geometry to mark the beginning and end of each virtual HDD. VDD also identifies the start and end locations of the manageability engine metadata area, such as the start and end locations of metadata 182. The VDD and ME metadata may not be encrypted by encryption engine 150, but rather the contents of metadata 182 are protected by I/O command decode module 140 and Manageability Engine (ME) 130.

In one embodiment, the metadata 182 includes AHCI file system blocks, pre-boot authentication (PBA) code, and PBA metadata. The AHCI file system is used by a firmware storage driver, which is executable by the processor 110. Metadata 182 may also include packaged DEKs 184, device configuration data, drive transition state information, and drive migration packets that may be used to migrate a device, such as SATA storage device 180, to another platform. The migration package also contains a copy of the DEK184 wrapped with a recovery key that is not specifically associated with the platform. The metadata 182 may also contain an identifier of the PBA executable and a storage area that includes PBA code to be executed during pre-boot on the host processor 110 prior to loading the host operating system. For example, the storage area containing PBA code may be part of flash memory 190. Access to the PBA area is allowed by code executing on host processor 110 through the use of VECI 111c via I/O command decode module 140 or through the use of the host command interface of HECI 111b via Manageability Engine (ME) 130. The I/O command decode module 140 ensures that requests to access the PBA storage area are limited to the storage range in which the PBA executables are stored, since the PBA code executes on the host processor 110.

When I/O command decode module 140 SATA virtualization firmware 243 reads virtual drive definition metadata containing metadata descriptor information stored in metadata 182 (which is stored on SATA storage device 180) in step 320 "I/O command decode module reads virtual drive definition metadata containing metadata descriptor information," the metadata descriptor information may include multiple examples of wrapped device encryption keys, such as DEK184, within device metadata 182. For example, the DEK184 may be wrapped with a platform-specific device wrapping key and a recovery key that is independent of the platform 100. Since there may be multiple examples of device encryption keys, there is a need to determine the location of a particular device encryption key that may be unwrapped using the user authentication credentials involved in performing a system reset.

As described above, the user performing the system reset will have an associated user wrapping key for wrapping the device wrapping key. The user wrapping key/device wrapping key is stored in device metadata 289 of flash memory 190. Control continues to step 330 "I/O Command Decode Module locates user authentication metadata offset and reads device metadata". In step 330, I/O command decode module 140 utilizes the metadata descriptor information to locate a user authentication metadata offset within flash memory 190 to perform a system reset with user credentials. User authentication metadata and other device metadata are read from the location of flash memory 190 identified by the offset.

After reading device metadata 298 from flash memory 190 in "I/O Command decoding Module locates user authentication metadata offset and reads device metadata" step 330, control proceeds to "ME protected device manager stores device metadata in secure storage" step 340. For example, ME protected device manager 235 may store device metadata including user authentication credentials for SATA storage device 180 in device metadata 298 of flash memory 190 for later access by Manageability Engine (ME) 130. Control then continues to step 350 "ME protected device manager waits for manageability operation command to issue". For example, ME protected device manager 235 waits for manageability operation commands, such as an unlock command, to access SATA storage device 180. Upon receiving the manageability operation command, ME protected device manager 235 may access the stored metadata to obtain user authentication credentials and/or other information needed to access SATA storage device 180.

Fig. 4 is a flow diagram of a method performed upon receiving a command to unlock a device protected by an encryption, user identity authentication, and password protection scheme in accordance with one embodiment of the present invention. The method of fig. 4 will be described as being performed by components of the system of fig. 2, but the method is not limited to such an implementation. Two examples of method flows are provided in fig. 4, depending on the origin of the request to unlock the protected device. The method steps contained in the remote unlock block 402 involve processing a remote unlock command, for example, an unlock command received from the management console 166 via a secure communication channel such as the OOB communication channel 168. The method steps contained in the USB unlock block 418 involve processing a lock command in conjunction with the USB device storing the token to unlock the storage device.

The method steps in remote unlock block 402 for processing a remote unlock command begin with "management console triggers remote unlock request for SATA device" step 404. Management console 166 may initiate the request in response to enterprise management policies, or management console 166 may act in response to a notification from Manageability Engine (ME) 130 that a device, such as SATA storage device 180, should be unlocked. Management console 166 triggers a request to unlock the encrypted SATA device via Manageability Engine (ME) 130 and chipset/secure partition 120 when there is no user at the keyboard, when there is a user but the user cannot successfully pass authentication of the platform, when the platform is in a low power state (e.g., one of Advanced Configuration Power Interface (ACPI) Sx power states S1-S5), when the system is connected via a wired or wireless network or outside of a corporate firewall but the device is inaccessible, and when the host operating system of the system fails.

Control proceeds from "management console triggers remote unlock request for SATA device" of step 404 to "management console connects to secure partition of step 406"; a disc unlock command including a token-1 and a device password is transmitted. The management console 166 may utilize an independently secure and encrypted channel, such as the OOB communication channel 168, to send a security command that indicates an unlock operation to the embedded security subsystem provided by the chipset/secure partition 120. When a secure communication channel, such as OOB communication channel 168, is established between management console 166 and chipset/secure partition 120, identity management firmware 239 utilizes Kerberos authentication to authenticate management console 166 and Manageability Engine (ME) 130. If a remote unlock request is initiated by Manageability Engine (ME) 130, management console 166 may obtain user credentials, such as a username and password of a user associated with platform 100, after establishing the secure communication channel. If a remote unlock request is initiated by management console 166, administrator user credentials may be used for platform 100. The management console 166 utilizes these user credentials to obtain the device's associated password (e.g., device 180 password 266B) and a token (e.g., token-1266A) for decrypting the device from the management database 266.

At step 406 "the management console connects to the secure partition; in sending a disc unlock command "containing a token-1 and a device password, the device password is contained in the unlock command so that the device can be unlocked using the device password. By including token-1 in the command, the user wrapping key/device wrapping key may be identified in, for example, device metadata 298. The user wrapping key/device wrapping key may be used to decrypt the encrypted blocks of the storage device, including metadata 182 containing a device encryption key 184.

From step 406 "the management console connects to the secure partition; sending a disk unlock command containing token-1 and a device password, control proceeds to step 408 "ME protected device manager verifies the command originating from the trusted console". Kerberos authentication credentials necessary to establish a secure communication channel between management console 166 and chipset/secure partition 120 may be utilized to verify that the command originated from trusted management console 166. Control then continues to step 410 "ME protected device manager utilizes token-1 to unwrap a copy of the DEK in the device metadata". As described above, once protected device manager 235 accesses device 180 password 266B to unlock SATA storage device 180, protected device manager 235 may make a copy of the device wrapping key stored in device metadata 298 of flash memory 190. The device wrapping key may be used to unwrap the device encryption key contained in the device metadata of each SATA device attached to the platform.

Once ME protected device manager 235 obtains the device encryption key for the encrypted storage device, control proceeds to "ME Security/Key management firmware writes DEK into encryption engine's key slot register corresponding to SATA device" step 412. The device encryption Key may be stored in a Key slot register within encryption engine 150 as described in inventor's Ned Smith patent application 12/319210 entitled "encryption Use of chip Key management services for Encrypted Storage Devices," which is incorporated herein by reference. Then, when accessing the device, the encryption engine 150 decrypts the data stored on the corresponding device using the stored device encryption key from the corresponding key slot register.

After the device encryption key is made accessible to encryption engine 150 in "ME Security/Key management firmware writes DEK to encryption engine's keyway register corresponding to the SATA device" step 412, control proceeds to "ME protected device manager performs manageability operations (which may include booting the OS)" step 414. For example, in response to a remote unlock command, ME protected device manager 235 unlocks the device, which may include providing a device password to unlock the device and decrypt blocks of the encrypted device using encryption engine 150. If the device is further encrypted by host software, manageability operations may require the management console 166 to communicate with trusted host software to further decrypt the device. In response to the USB unlock command, ME protected device manager 235 similarly unlocks the device, including unlocking the device with the device password and decrypting blocks of the encrypted device with encryption engine 150. Depending on the particular manageability operation command being processed, the platform may be rebooted, including booting the host operating system.

After performing manageability operations in "ME protected device manager performs manageability operations (which may include booting the OS)" step 414, control proceeds to "ME protected device manager resets the platform causing the SATA device to become locked again" step 416. ME protected device manager 235 performs the steps described with reference to fig. 3 to reset the system, thereby causing the storage device to be locked again.

As described above, FIG. 4 also includes method steps for manually unlocking the device using a USB unlock command. The method steps in the USB unlock block 418 for processing the USB unlock command begin with step 420 "the BIOS application prompts the user to insert a USB device containing token-2". Upon system startup, the BIOS application prompts the user to insert a USB device containing token-2 to enable the user to access a device such as SATA storage device 180. Such a BIOS prompt may be provided, for example, if the user is unable to provide a password to access the device. Control proceeds to step 422 "BIOS reads token-2 and sends it to ME protected device manager via HECI/DHCI". The BIOS application reads the token-2 provided by the user and sends the token-2 to the ME protected device manager 235 via the HECI 111 b. Control then continues to step 424 "ME protected device manager utilizes token-2 to unwrap a copy of the DEK in the device metadata". As described above, once protected device manager 235 accesses the unlocking token to unlock SATA storage device 180, protected device manager 235 can make a copy of the Device Wrapping Key (DWK) stored in the device metadata, such as flash memory 190 data region 198. The DWK may be used to decrypt the DEK contained in the device metadata of each SATA device attached to the platform. After the device encryption key is made accessible to encryption engine 150 in step 412 "ME Security/Key management firmware writes DEK to encryption engine's keyway register corresponding to the SATA device," control proceeds as described above.

The systems of fig. 2, 3 and 4 enable unlocking of the device without the involvement of the host operating system. Special considerations are necessary if it is desired to allow access to any device attached to the system after authenticating the credentials of the user of the system. This authentication is typically done at boot time of the system, so that the dynamically attached device omits confirmation of the user's authentication credentials without rebooting the system. Preferably, the user's access to the hot-plugged device can be authenticated, but rebooting the system to confirm the user's credentials is too burdensome. Enabling authentication of dynamic attachment of storage devices may be used, for example, to ensure that dynamic replacement of storage devices that are part of a RAID array is performed by an authorized user.

Similar problems exist in devices that utilize ATA command locking or encryption. ATA-locked or ATA-encrypted devices are unlocked by BIOS at system start-up, and thus cannot be hot-plugged into the system. Rebooting the system is necessary to unlock or decrypt the device before data on the device can be accessed.

The system of fig. 5A and 5B enables regulating access to hot-plugged devices when authenticating credentials of a user of the system. The hot-plugged device may be unlocked and/or decrypted and the user's credentials may be validated without rebooting the system, even if the device is locked or encrypted using ATA commands.

The system of fig. 5A and 5B requires first authenticating the credentials of a user of the system to allow access to any of a plurality of devices attached to the system. A secure partition of a system that is isolated from a host operating system of the system intercepts an event indicating that a new device is attached to the system. Requesting second credentials for accessing the new device without booting the system, authenticating the second credentials, and enabling access to the new device after authenticating the second credentials. A hot-plug event for the new device is delivered from the secure partition to the host operating system.

Requesting second credentials for accessing the new device may include displaying a request for the second credentials with a trusted path connection to a display device and receiving the second credentials with a user input device. Authenticating the first and second credentials may include authenticating the first and second credentials with a trusted third party. The second credential may include a password for the new device, and enabling access to the new device may include utilizing the password to unlock the new device. The second credentials may include a user identifier, and enabling access to the new device may include providing the user identifier to a trusted third party and enabling access to the new device if the trusted third party authenticates the user identifier.

FIG. 5A shows further details of the system of FIG. 1 in enabling devices protected by encryption, user identity authentication, and password protection schemes to be dynamically attached and user authentication credentials to be dynamically reconfirmed without rebooting in accordance with one embodiment of the present invention. Manageability engine core 531, manageability engine public services 533, security/key management firmware 537, I/O module core 541, and SATA virtualization firmware 543 operate as described with reference to corresponding components of the system of FIG. 2.

Within Manageability Engine (ME) 130, identity management firmware Kerberos client 539A interacts with identity management firmware Kerberos server 539B to authenticate a user. Kerberos client 539A implements the Kerberos protocol with a key distribution center (e.g., key distribution center 164 of fig. 1). Kerberos client 539A may utilize trusted I/O firmware 536 (if available) to obtain credentials from a user of the system using a trusted path connection to a display device and a user input device. Kerberos client 539A may provide user credentials to key distribution center 164 and obtain Kerberos tickets to access Kerberos services such as Kerberos server 539B. Kerberos server 539B enables access to SATA storage device 180 upon receiving a Kerberos ticket indicating that credentials of a user accessing the device have been authenticated. The Kerberos ticket may include an extension field containing a user token, such as token-1266A of fig. 2, that enables generation of a user wrapping key that may be used to unwrap the device wrapping key and the device encryption key as described above with reference to fig. 2. The Kerberos ticket may also include an extension field containing a device password, such as device 180 password 266B of fig. 2, that may be used to unlock the device.

Within I/O command decode module 140, hot plug virtualization firmware 545 decodes hot plug events received by I/O controller 170 and forwards the hot plug events to host operating system 115 after processing those events. The operation of hot plug virtualization firmware 545 will be described in further detail with reference to FIG. 5B.

FIG. 5B is a flow chart of a method performed by the system of FIG. 5A in recognizing a hot plug event of a device. In action 5.1, I/O controller 170 detects a SATA hot-plug event, where SATA storage device 180 has been dynamically attached to platform 100. In action 5.2, hot-plug virtualization firmware 545 intercepts the hot-plug event and interacts with SATA virtualization firmware 543 to discover the attributes of the device. Hot-plug virtualization firmware 545 requests access to the hot-plug device from Kerberos client 539A of identity management firmware 539. If the device is locked using an ATA cryptographic scheme, ATA encryption, and/or chipset-based encryption, hot-plug virtualization firmware 545 may also notify Kerberos client 539A to lock SATA storage device 180 as part of the request to access the device.

In action 5.4, Kerberos client 539A obtains user information such as user authentication credentials. Kerberos client 539A may determine whether the user's credentials are cached locally within Manageability Engine (ME) 130, such as within SRAM 122. If the user's credentials are cached locally, actions 5.4 and 5.5 may be omitted. If the user's credentials are not cached locally, then these user authentication credentials may be obtained via trusted I/O firmware 536 on platform 100 (if available). Trusted I/O firmware 536 displays the request for credentials using a trusted path connection (e.g., a trusted path connection to a display device) and receives credentials using a trusted path connection to a user input device (e.g., a keyboard). In embodiments where trusted I/O firmware 536 is not available on platform 100, a notification may be sent to a host agent (not shown) running on processor 110 that a new device has been attached. The host agent may collect the user's credentials and connect to the chipset/secure partition 120 to unlock the device and make the device visible to the host operating system 115.

In action 5.5, Kerberos client 539A obtains a Kerberos ticket from key distribution center 164. In one embodiment, the Kerberos ticket is provided with an unlock token for the user of SATA storage device 180 (e.g., token 1266A in FIG. 2) and an ATA password belonging to the user (e.g., device 180 password 266B in FIG. 2). The unlock token and the ATA password for the user may be obtained from a directory service, such as management console 166 of fig. 1 and 2. The Kerberos ticket validates the authenticity of the user credentials to receive services from Kerberos server 539B. In one embodiment, Kerberos server 539B enables Kerberos client 539A to access all other services within Manageability Engine (ME) 130, such as services from security/key management firmware 537 and protected device manager 539. In other embodiments, a separate Kerberos ticket may be obtained to access services provided by other Manageability Engine (ME) 130 components, such as security/key management firmware 537. In one embodiment, the user's unlock token for SATA storage device 180 and the ATA password belonging to the user are delivered as extension fields that are part of the Kerberos session key.

In action 5.6, Kerberos client 539A confirms the user's credentials with Kerberos server 539B. In an alternative embodiment, Kerberos client 539A may confirm the user's credentials directly with key distribution center 164 without going through a local Kerberos server, such as Kerberos server 539B. For example, Kerberos client 539A may obtain a Kerberos ticket to access a different user authentication service, such as an active directory service that will return token-1266A and device 180 password 266B in a subsequent exchange. In one embodiment, management console 166 in fig. 1 and 2 may proxy connections to different user authentication services and/or host the user authentication services themselves.

Actions 5.7 through 5.10 describe actions taken when hot-plugged SATA storage device 180 is protected by an inherent locking mechanism such as an ATA password or ATA encryption. If the device is not protected by an inherent locking mechanism such as an ATA password or ATA encryption, steps 5.7 to 5.10 will be omitted.

In action 5.7, in the event that hot-plugged SATA storage device 180 is locked with an ATA password, Kerberos client 539A provides the user's ATA password to protected device manager 535. In action 5.8, protected device manager 535 provides the user's ATA password to SATA virtualization firmware 543 of I/O command decode module 140. In action 5.9, SATA virtualization firmware 543 sends an ATA command to I/O controller 170 to unlock SATA storage device 180. In action 5.10, I/O controller 170 unlocks SATA storage device 180 with an ATA command. As described above, if SATA storage device 180 is encrypted by encryption engine 150, security/key management firmware/Kerberos server 537 may work with identity management firmware/Kerberos client 539 to derive a user wrapping key using the user's unlock token contained in the extension field of the Kerberos ticket. The user wrapping key may be used to access the device wrapping key and the device encryption key from SATA storage device 180.

Actions 5.11 and 5.12 describe actions taken in encrypting a hot-plugged SATA storage device 180 through encryption engine 150. If the hot-plugged SATA storage device is not encrypted by encryption engine 150, steps 5.11 and 5.12 will be omitted. If hot-plugged SATA storage device 180 is encrypted by chipset/secure partition 120 encryption engine 150, Kerberos client 539A may request security/key management firmware 537 to enable device decryption for hot-plugged SATA storage device 180 in act 5.11. As described above with reference to fig. 2, user credentials may be utilized to obtain a device encryption key. In action 5.12, device encryption key 184 is provided to encryption engine 150. As described above, the device encryption key may be written to a key register of encryption engine 150 and used by encryption engine 150 to decrypt blocks of a hot-plugged device, SATA storage device 180. If hot-plugged SATA storage device 180 is also protected by an ATA password, the device is unlocked using the steps described above with reference to acts 5.7 through 5.10 for unlocking SATA storage device 180 before the device encryption key stored on the device is accessible.

In action 5.13, Kerberos client 539A notifies hot-plug virtualization firmware 545 that access to SATA storage device 180 has been granted. As described with reference to acts 5.7 through 5.10, if SATA storage device 180 is locked with an ATA password, the device is unlocked. As described with reference to actions 5.11 and 5.12, if the device is encrypted by encryption engine 150, decryption has been enabled. In action 5.14, hot plug virtualization firmware 545 delivers the hot plug event to host operating system 115. Host operating system 115 then accesses the unlocked and decrypted data from SATA storage device 180. In response to receiving a hot-plug event, host operating system 115 may invoke a file system to mount SATA storage device 180 and/or to join SATA storage device 180 to a RAID array.

In the system described above with reference to fig. 1-5B, encryption of storage is performed by encryption engine 150 within chipset/secure partition 120. Further, the systems described above with reference to fig. 1-5B provide encryption and protected device management functionality within a secure partition of the system that is isolated from the host operating system. For example, encryption engine 150 resides within chipset/secure partition 120, protected device manager 235 of FIG. 2 resides in Manageability Engine (ME) 130 of chipset/secure partition 120, and SATA virtualization firmware 543 and hot plug virtualization firmware 545 of FIG. 5B reside within I/O command decode module 140 of chipset/secure partition 120.

Typically, auditable events are captured in auditing software running under control of the host operating system and/or BIOS. Because the management and encryption functionality described herein is isolated from the host operating system and BIOS, events executing within the secure partition are not captured by typical auditing software. However, it is desirable to capture and audit events that affect the management of protected devices and the encryption of stored data. It is also desirable to perform audit operations in an environment that is protected from potential damage by the host operating system and/or BIOS. It is also preferable to capture audit information in a timely manner within the secure environment where auditable events occur.

FIG. 6 illustrates further details of the system of FIG. 1 in managing protected devices according to one embodiment of the present invention. The operations of manageability engine core 631, manageability engine public services 633, protected device manager 635, security/key management firmware 637, and identity management firmware 639 are as described with respect to the corresponding components of fig. 2 and 5A.

In the embodiment shown in FIG. 6, Manageability Engine (ME) 130 includes manageability engine audit subsystem 638 and I/O command decode module 140 includes I/O module audit subsystem 648. Manageability engine audit subsystem 638 and I/O module audit subsystem 648 identify and process auditable actions that occur within their respective components of chipset/secure partition 120. Since I/O to storage data is prepared by I/O command decode module 140 and works directly with encryption engine 150 to encrypt data as it is written to storage, I/O module audit subsystem 648 captures auditable events that occur during I/O. In contrast, Manageability Engine (ME) 130 is not directly involved in I/O of the storage device, and thus manageability engine audit subsystem 638 captures auditable events related to management of the protected device. For example, manageability engine audit subsystem 638 captures events related to configuration and setup of the system to manage encryption, user authentication, device initialization and failures, encryption keys, theft detection, and other enterprise platform management policies.

Manageability engine audit subsystem 638 and I/O module audit subsystem 648 communicate via manageability engine controller interface (ME) 131. Manageability engine audit subsystem 638 may also communicate with remote audit administration service 640 within management console 166 via OOB communication channel 168, network controller 160, and out-of-band communication module 630.

In one embodiment, auditable events are defined in an audit policy. The audit policy may define auditable events that will generate audit event records as well as other negligible non-auditable events. Because auditing each event occurring within the system can significantly degrade the performance of the system, an audit policy is utilized to selectively capture events of particular interest according to organizational priorities and policies. In one embodiment, an audit bit mask is utilized as a selector to activate and deactivate different hardware and/or firmware components capable of detecting auditable events.

The event types in the audit policy may include: cryptographic system provision/de-provision events; a user management event; a device management event; a key management event; a device initialization event; a theft detection event; and a device failure event. Specific auditable events may include: events triggered by actions external to the secure partition of the system, such as events triggered by the host operating system that cause activity within the secure partition; and/or actions occurring within the secure partition, such as interrupts.

The externally triggered events may include: enabling or disabling theft protection services; create, delete or modify a user account; user login/logout success or failure; encryption keys generated or deleted for various types of encryption keys such as device encryption keys, device wrapping keys, and recovery keys; a device configured for encryption or decryption; device conversion or cancellation of conversion as a device for security management; device configuration of PASS _ THROUGH; device migration or device migration preparation; device Encryption Key (DEK) insertion or deletion from encryption engine registers; audit event policy registration or deregistration; recovery of platform or device metadata; a user of a local platform token; a change in encryption policy, such as a change in key strength, a key refresh, or a remote configuration of encryption policy; a transition between authenticated and unauthenticated encryption; a device unlock operation; the device failed. Internally triggered auditable events may include: a self-test failure of the manageability engine, the I/O command decode module, the encryption engine, and/or the interface to the secure partition; the alliance information processing standard self-test succeeds or fails; auditing and initializing faults; and/or memory failure.

When manageability engine audit subsystem 638 or I/O module audit subsystem 648 detects an event, it may be determined whether the detected event is one of the auditable events defined in the audit policy. If the detected event is one of the auditable events in the audit policy, the event is identified as an auditable event.

The audit policy may include instructions to service an audit event record for each auditable event. The audit policy may also specify actions to be taken when a log of auditable events cannot be logged. For example, manageability engine audit subsystem 638 or I/O module audit subsystem 648 may be configured to pause or resume (reverse its effect) operations that cannot write audit event records to audit logs. Further, the audit policy may specify the processing of exhausted audit storage log resources such that manageability engine audit subsystem 638 or I/O module audit subsystem 648 may be configured to overwrite the audit logs or stop writing audit event records to the audit logs.

In one embodiment, manageability engine audit subsystem 638 and I/O module audit subsystem 648 each generate an audit event record for the identified auditable event. The audit event record is written to an audit log that is isolated from the host operating system. In the embodiment shown in FIG. 6, manageability engine audit subsystem 638 writes auditable events to audit log 610, while I/O module audit subsystem writes auditable events to audit log 620. In one embodiment, audit log 610 is stored in an isolated region of flash memory, such as an isolated region of data region 198 of flash memory 190 of FIG. 1, while audit log 620 is stored in an isolated region of non-volatile memory, such as an isolated region of non-volatile memory storage 172 of FIG. 1. Since non-volatile memory is faster than flash memory, in one embodiment, if non-volatile memory is available, the audit event record is first written to an audit log (in this example, audit log 620) stored in non-volatile memory. Since I/O command decode module 140 prepares I/O to storage data and works directly with encryption engine 150 to encrypt the data as it is written to storage, I/O module audit subsystem 648 is coupled to faster audit log 620 stored in non-volatile memory to reduce latency in processing I/O events. Because manageability engine audit subsystem 638 is not directly involved in I/O, manageability engine audit subsystem 638 writes audit event records to a slower audit log 610 stored in flash memory, such as flash memory 190.

When audit log 610 and/or audit log 620 reach a threshold, manageability engine audit subsystem 638 may notify remote audit administration service 640 to service the audit log. In one embodiment, audit administration service 640 copies the contents of audit logs 610 and 620 to a remote storage device and resets the thresholds. Audit management service 640 does not interrupt operation of manageability engine audit subsystem 638 or I/O module audit subsystem 648, thereby continuing to write audit event records to their respective audit logs 610 and 620 while auditable events are identified. When audit log 620 approaches the threshold, I/O module audit subsystem 648 notifies manageability engine audit subsystem 638 via MECI 131 so that manageability engine audit subsystem 638 can send service requests to audit administration service 640.

In one embodiment, manageability engine audit subsystem 638 works with audit administration service 640 to manage all audit subsystems active within the secure partition. Manageability engine audit subsystem 638 may perform the functions of other audit subsystems, such as I/O module audit subsystem 648, when these other audit subsystems are overloaded and unable to handle auditable events. Manageability engine audit subsystem 638 may also service audit logs for other audit subsystems. In one embodiment, manageability engine audit subsystem 638 requires the registration of other audit subsystems. Registration is used to notify manageability engine audit subsystem 638 that there are local audit logs, such as audit log 620, maintained by other audit subsystems. Registration may also be used to inform manageability audit subsystem 638 whether to reroute discrete auditable events for processing and/or whether to request servicing of audit logs.

In one embodiment, the operation of manageability engine audit subsystem 638 and I/O module audit subsystem 648 is controlled by enterprise domain privileges using Kerberos tickets. In one embodiment, an auditable event performed in a secure partition of a system is identified, wherein the secure partition is isolated from a host operating system of the system. Generating an audit event record for the auditable event and writing the audit event record to an audit log isolated from the host operating system. In one embodiment, a plurality of auditable events are defined in an audit policy, the audit policy including instructions to service each auditable event of the plurality of auditable events, and identifying the auditable event includes determining whether the detected event is one of the plurality of auditable events defined in the audit policy.

The audit log may be a first audit log of a plurality of audit logs accessible only from within the secure partition. Each audit log of the plurality of audit logs is isolated from the host operating system. In one embodiment, it is determined whether a first audit log is available. If the first audit log is available, the audit event record is sent to a first audit subsystem associated with the first audit log and the first audit subsystem performs writing the audit event record to the first audit log. If the first audit log is not available, the audit event record is sent to a second audit subsystem associated with a second audit log of the plurality of audit logs, and the second audit subsystem performs writing the audit event record to the second audit log.

In one embodiment, the latency of write operations to the first audit log is monitored. If the wait time reaches a predetermined threshold, the subsequent write operation is transferred to a second audit subsystem such that a subsequent audit event record for the subsequent write operation can be written to a second audit log. In another embodiment, if the wait time reaches a predetermined threshold, a request to service the first audit log is sent to the second audit subsystem. The second audit subsystem services the first audit log by moving the audit event record from the first audit log to another location, such as a third audit log. In one embodiment, the second audit subsystem schedules the remote management application to service the third audit log, the remote management application establishes a secure communication channel with the secure partition, and the remote management application services the third audit log via the secure communication channel.

In one embodiment, a request to service an audit log is received from a secure partition of a requesting system, wherein the secure partition is isolated from a host operating system of the requesting system, the audit log contains an audit event record of auditable events performed in the secure partition, and the audit log is isolated from the host operating system of the requesting system. Establishing a secure communication channel with a secure partition; and services the audit log via a secure communication channel. Servicing the audit log may include processing the auditable event in accordance with an audit policy.

FIG. 7 is a flow diagram of a method performed upon detection of a potentially auditable event occurring within a secure partition of a system according to one embodiment of the invention. Upon detecting an event occurring within a secure partition, such as chipset/secure partition 120, in step 702 "detect event", control proceeds to decision point 704 "is an auditable event? ". At decision point 704 "is an auditable event? "where logic encoded in hardware and/or a corresponding audit subsystem (manageability engine audit subsystem 638 or I/O module audit subsystem 648) may examine the audit policy to determine whether the event is auditable. In one embodiment, an audit bit mask is utilized to activate different hardware and/or firmware components capable of detecting auditable events. At decision point 704 "is an auditable event? "evaluation of the audit bit mask determines whether the event is auditable.

At decision point 704 "is an auditable event? "if the event is auditable, control proceeds to" generate an audit event record "at step 706. Audit event records may be generated by logic encoded in hardware and/or a corresponding audit subsystem (manageability engine audit subsystem 638 or I/O module audit subsystem 648). After generating the audit event record, control proceeds to decision point 708 "is NVM log available? ". As previously discussed, if a non-volatile memory log is available, it is preferable to write the audit event record to non-volatile memory to reduce the latency associated with processing the event. At decision point 708 "is NVM log available? "if the NVM log is available, control proceeds to" send event record to I/O Module Audit subsystem "step 710. At step 710 "send event record to I/O module audit subsystem", the event record is sent to I/O module audit subsystem 648.

From step 710 "send event record to I/O module audit subsystem", control proceeds to decision point 712 "is threshold reached? ". An example of a threshold being reached is when I/O module utilization falls below a normal level and/or the audit log becomes full. When the threshold is reached, control proceeds to "send threshold status to manageability engine audit subsystem" step 718. For example, when I/O module utilization falls below a threshold level, audit activity may need to be offloaded to manageability engine audit subsystem 638 and/or to service audit log 620. When step 718 "send threshold status to manageability engine audit subsystem" is performed, manageability engine audit subsystem 638 takes appropriate action to manage the threshold being reached according to the audit policy. For example, manageability engine audit subsystem 638 may schedule audit administration services 640 to service logs and/or copy logs that reach a threshold to other archive storage devices. From step 718, "send threshold status to manageability engine audit subsystem," control proceeds to "write event records to audit log" step 715, where the audit event records that caused the threshold to be reached are written to the log by manageability engine audit subsystem 638.

From decision point 712 "is threshold reached? ", if the threshold is not reached, control proceeds to" write event records to audit logs "step 715, where the respective audit subsystem writes audit event records to its respective log. Control then continues to "execute event" step 714, where the event is executed and processing of auditable events is complete.

At decision point 708 "whether NVM logs are available", if NVM logs are not available, control proceeds to step 716 "send event records to manageability engine audit subsystem". The audit event records are sent to manageability engine audit subsystem 638. Manageability engine audit subsystem 638 then writes the event record to audit log 610 in "write event record to audit log" step 715. Control proceeds to "execute event" step 714, where the event is executed and processing of auditable events is complete.

At decision point 704 "is an auditable event? If the event is not auditable, control proceeds to "execute event" step 714. The event is executed and the processing of the event is completed.

The processing of auditable events may be performed by logic encoded in hardware and/or by firmware. Initialization of chipset/secure partition 120 components, such as Manageability Engine (ME) 130, I/O command decode module 140, and encryption engine 150, are auditable events that may be encoded into the hardware of those respective components and/or included in the firmware of those respective components. Similarly, hardware and/or firmware of controllers and interfaces such as HECI 111b, VECI 111c, network controller 160, USB controller 175, I/O controller 170 may include logic for handling auditable events.

Audit event processing may be performed within Manageability Engine (ME) 130 at initial configuration and during operation of components of Manageability Engine (ME) 130, such as during operation of security/key management firmware 237 of FIG. 2. For example, when security/key management firmware 237 writes a Device Encryption Key (DEK) into a corresponding register of encryption engine 150, when a storage device is to be encrypted or the DEK is removed from a corresponding register of encryption engine 150, an audit event may be triggered when encryption is disabled.

Audit event processing may also be performed when data is transferred from I/O controller 170 to encryption engine 150 in plaintext form (for write operations) and when encryption engine 150 returns data in ciphertext form. Audit events over the channel between I/O controller 170 and encryption engine 150 provide evidence that data is being encrypted, but an audit policy may limit auditing these events to periodic compliance testing.

Audit event processing may be performed at Manageability Engine Controller Interface (MECI) 131 because coordination between audit subsystems may be communicated via MECI 131. Initial configuration of I/O command decode module 140 is also performed via MECI 131 and will generate auditable events.

Audit event processing may be generated by communications from processor 110 via interfaces HECI 111b and VECI 111 c. For example, ATA security commands that pertain to the locked state of a device, as well as commands that propagate to I/O controller 170 or USB controller 175 via these interfaces, generate auditable events. In addition, HECI commands for user authentication, encryption, security, key management, and status are also auditable events. Commands for initializing controllers such as I/O controller 170, USB controller 175, and network controller 160 are also auditable events. Audit log storage and configuration commands are also auditable, as are audit subsystem communications with remote audit administration service 640 of FIG. 6. Attaching a device to platform 100 via USB controller 175 and/or I/O controller 170 is also an auditable event.

By configuring certain events in an audit policy to be auditable or not auditable, the audit system can be fine-tuned to balance performance, storage capacity, and security. By managing the audit subsystem with a remote management console and audit administration service via a secure communication channel, the integrity of the audit information may be protected.

FIG. 8 illustrates a virtual machine environment for implementing secure partitioning to manage actions such as protecting a device with encryption, user authentication, and password protection schemes, according to one embodiment of the invention. If platform 800 is virtualized, it may include only a single processor, but a virtual machine monitor ("VMM 830") on the host machine may present multiple abstractions and/or views of the host machine, such that the underlying hardware of the host machine appears as one or more independently operating virtual machines ("VMs"). VMM 830 may be implemented in software (e.g., as a stand-alone program and/or a component of a host operating system), hardware, firmware, and/or any combination thereof. VMM 830 manages allocation of resources on the host and performs context switching as needed to cycle between the various VMs according to a round-robin or other predetermined scheme. One of ordinary skill in the art will readily appreciate that although only one processor ("processor 805") is shown, embodiments of the invention are not so limited, and multiple processors may also be used in a virtualized environment.

Although only two VM partitions are shown ("VM 810" and "VM 820", collectively referred to hereinafter as "VMs"), these VMs are merely illustrative and additional virtual machines may be added to the host machine. VM 810 and VM 820 may each function as a self-contained platform to run their own "guest operating systems" (i.e., operating systems hosted by VMM 830, shown as "guest OS 811" and "guest OS 821" and collectively referred to hereinafter as "guest OS") and other software (shown as "guest software 812" and "guest software 822" and collectively referred to hereinafter as "guest software").

Each guest OS and/or guest software operates as if it were running on a dedicated computer rather than a virtual machine. That is, each guest OS and/or guest software may expect to control various events and access hardware resources on platform 800. Within each VM, the guest OS and/or guest software may behave as if they were actually running on the physical hardware of platform 800 ("host hardware 840", which may include network controller 860).

Those of ordinary skill in the art will readily appreciate that physical hardware partitions with specialized processors, such as Manageability Engine (ME) 130 in FIG. 1, may provide a higher level of security than virtualized partitions (as shown in FIG. 8), but embodiments of the invention may also be implemented in environments that provide different levels of security and/or combinations of these environments. One of ordinary skill in the art will also readily appreciate that an ME, AMT, or PRL platform may be implemented within a virtualized environment. For example, VM 820 may be dedicated as an ME partition on a host, while VM 810 runs typical applications on the host. In this case, the host may or may not include multiple processors. For example, if the host does include two processors, VM 820 may be assigned to the other processor, while VM 810 (and other VMs on the host) may share the resources of processor 805. On the other hand, if the host includes only a single processor, then that processor may serve both VMs, while VM 820 may still cooperate with VMM 830 and be isolated from the other VMs on the host. For simplicity, embodiments of the invention are described in a Manageability Engine (ME) environment, but embodiments of the invention are not so limited. Rather, any reference to a manageability engine, ME, a "partition," a "secure partition," a "security partition," and/or a "management partition" shall include any physical and/or virtual partition (as described above).

At startup or when a new device is hot-plugged into the platform, VMM 830 assigns the device to VM 810 or 820. To perform audits within chipset/secure partition 120 in a virtualization environment (e.g., the virtualization environment described in FIG. 8), VMM 830 manages audit mask profiles for each of VMs 810 and 820. When a device is assigned to a VM 810 or 820, the VM's corresponding audit mask profile is associated with chipset/secure partition 120. VMM 830 generates an audit event record each time a VM audit mask profile associated with chipset/secure partition 120 changes. As such, the VM 810 or 820 that initiated the auditable event is represented in the audit event record. For example, VM 810 or 820 issuing storage I/O commands to a device is identified in an audit event record.

If the device is hot-plugged into the platform, the VM 810 or 820 that received the device assignment is identified in the audit event record. When a hot-plug event is detected, the I/O command decode module 140 may need to determine whether the VM 810 or 820 currently associated with the chipset/secure partition 120 is authorized to receive the device assignment. Before assigning devices and may determine the correct audit mask profile assigned to chipset/secure partition 120, the internal audit mask profile may be utilized to audit events following a hot-plug event until device assignment occurs.

VMM 830 may identify the currently active VM audit mask profile to the chipset/secure partition by writing the currently active audit mask profile to flash memory 190. Flash memory 190 is also used to maintain user account metadata associated with each VM. When the storage device is unlocked using the device password or device encryption key, additional checks may be performed to ensure that the user account metadata in flash memory 190 corresponds to the VM assigned to the device.

VMM 830 ensures that transient VM environments do not result in unauthorized assignment of drivers. In one embodiment, VMM 830 generates a GUID (globally unique ID) for each VM 810 and 820. The GUID is used for partition metadata in flash memory 190.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the invention may be implemented as computer programs executing on programmable systems comprising at least one processor, a data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.

Program code may be applied to input data to perform the functions described herein and generate output information. Embodiments of the invention also include machine-accessible media containing instructions for performing the operations of the invention or containing design data, such as HDL, defining the structures, circuits, devices, processors, and/or system features described herein. These embodiments may also be referred to as program products.

These machine-accessible storage media may include, but are not limited to, tangible particle arrangements manufactured or formed by a machine or device, including storage media such as: a hard disk; any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks; a semiconductor device such as a Read Only Memory (ROM), a Random Access Memory (RAM) (e.g., a Dynamic Random Access Memory (DRAM), a Static Random Access Memory (SRAM)), an Erasable Programmable Read Only Memory (EPROM), a FLASH programmable memory (FLASH), an Electrically Erasable Programmable Read Only Memory (EEPROM), a magnetic or optical card; or any other type of media suitable for storing electronic instructions.

The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor, which may be, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The programs may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The programs can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

Embodiments of methods and systems for managing devices protected by encryption, user authentication, and password protection schemes are presented herein. While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that numerous changes, variations and modifications can be made without departing from the scope of the appended claims. Thus, those skilled in the art will recognize that changes and modifications may be made without departing from the invention in its broader aspects. The appended claims are to encompass within their scope all such changes, variations, and modifications as are within the true scope and spirit of this invention.

Claims (22)

1. A computer-implemented method, comprising:

receiving a request to unlock a cryptographic device coupled to a system, wherein the request is received by a secure partition of the system via a secure communication channel established between a trusted remote console and the secure partition, and the secure partition is isolated from a host operating system of the system;

the secure partition unlocking the cryptographic device in response to the request without involvement of the host operating system;

performing a management operation after unlocking the cryptographic device, wherein the request further specifies a management operation to be performed; and

booting the host operating system after performing the management operation.

2. The method of claim 1, further comprising:

receiving, by the secure partition, a token from the trusted remote console; and

the token is utilized to unlock a key used to encrypt blocks of the encryption device.

3. The method of claim 2, further comprising:

obtaining the key from a secure storage area of the cryptographic device, wherein the secure storage area is hidden from the host operating system.

4. The method of claim 1, further comprising:

confirming that the request originated from the trusted remote console prior to unlocking the cryptographic device.

5. The method of claim 1, wherein unlocking the cryptographic device is performed when a host operating system of the system fails.

6. The method of claim 1, wherein unlocking the cryptographic device is performed without user involvement of the system.

7. The method of claim 1, wherein,

the request includes a password for the encryption device; and is

Unlocking the encrypted device includes unlocking the encrypted device using the passcode.

8. A computing platform device, comprising:

at least one processor;

a secure partition isolated from a host operating system executing on the processor; and

memory including instructions for a device manager executing in the secure partition, the instructions performing the steps of:

receiving a request to unlock a cryptographic apparatus coupled to the device, wherein the request is received by the secure partition via a secure communication channel established between a trusted remote console and the secure partition, and the secure partition is isolated from the host operating system;

unlocking the cryptographic device in response to the request without involvement of the host operating system;

performing a management operation after unlocking the cryptographic device, wherein the request further specifies a management operation to be performed; and

booting the host operating system after performing the management operation.

9. An apparatus in a computer, comprising:

means for receiving a request to unlock a cryptographic device coupled to a processing system, wherein the request is received by a secure partition via a secure communication channel established between a trusted remote console and the secure partition, and the secure partition is isolated from a host operating system of the processing system;

means for unlocking the cryptographic device in response to the request without involvement of the host operating system;

means for performing a management operation after unlocking the cryptographic device, wherein the request further specifies a management operation to be performed; and

means for booting the host operating system after performing the management operation.

10. A computer-implemented method, comprising:

establishing a secure communication channel between a trusted remote console and a secure partition of a system, wherein the secure partition is isolated from a host operating system of the system;

sending a request to unlock a cryptographic device coupled to the system, wherein the request is sent to the secure partition via the secure communication channel, and wherein the cryptographic device is unlocked by the secure partition without involvement of a host operating system of the system; and

specifying in the request a management operation to be performed after unlocking the cryptographic device, wherein the secure partition performs the management operation after unlocking the cryptographic device.

11. The method of claim 10, further comprising:

providing a token from the trusted remote console to the secure partition in the request, wherein the secure partition utilizes the token to unlock a key for decrypting blocks stored on the encryption device.

12. The method of claim 10, further comprising:

providing a password for the encryption device in the request, wherein the password is utilized by the secure partition to unlock the encryption device.

13. A computer-implemented method, comprising:

a first credential to authenticate a user of a system prior to allowing access to any of a plurality of devices attached to the system;

intercepting an event indicating that a new device is attached to the system, wherein the intercepting is performed by a secure partition of the system and the secure partition is isolated from a host operating system of the system;

requesting second credentials for accessing the new device, wherein the second credentials are requested without booting the system;

authenticating the second credential;

enabling access to the new device after authenticating the second credential; and

delivering a hot plug event for the new device to the host operating system.

14. The method of claim 13, wherein,

requesting the second credentials to access the new device includes displaying a request for the second credentials with a trusted path connection to a display device and receiving the second credentials with a user input device.

15. The method of claim 13, wherein,

enabling access to the new device includes utilizing an intrinsic command for the device to enable decryption of the new device.

16. The method of claim 13, wherein,

the second credential comprises a password for the new device; and is

Enabling access to the new device includes unlocking the new device with the password.

17. The method of claim 13, wherein,

the second credentials comprise a user identifier; and is

Enabling access to the new device comprises: providing the user identifier to a trusted third party and enabling access to the new device if the user identifier is authenticated by the trusted third party.

18. A computing platform device, comprising:

at least one processor;

a secure partition isolated from a host operating system executing on the processor; and

a memory including instructions for firmware executing in the secure partition, the instructions for performing the steps of:

a first credential to authenticate a user of a system prior to allowing access to any of a plurality of devices attached to the system;

intercepting an event indicating that a new device is attached to the system, wherein the intercepting is performed by the secure partition;

requesting second credentials for accessing the new device, wherein the second credentials are requested without booting the system;

authenticating the second credential;

enabling access to the new device after authenticating the second credential; and

delivering a hot plug event for the new device to the host operating system.

19. An apparatus in a computer, comprising:

means for authenticating a first credential of a user of a system prior to allowing access to any of a plurality of devices attached to the system;

means for intercepting an event indicating that a new device is attached to the system, wherein the intercepting is performed by a secure partition, and the secure partition is isolated from a host operating system of the system;

means for requesting second credentials for accessing the new device, wherein the second credentials are requested without booting the system;

means for authenticating the second credential;

means for enabling access to the new device after authenticating the second credential; and

means for delivering a hot plug event of the new device to the host operating system.

20. A computer-implemented method, comprising:

identifying an auditable event performed in a secure partition of a system, wherein the secure partition is isolated from a host operating system of the system;

generating an audit event record of the auditable event; and

writing the audit event record to an audit log, wherein the audit log is isolated from the host operating system;

wherein:

the audit log is a first audit log of a plurality of audit logs,

the plurality of audit logs are accessible only from within the secure partition, an

Each audit log of the plurality of audit logs is isolated from the host operating system.

21. The method of claim 20, wherein the method further comprises:

determining whether the first audit log is available;

if the first audit log is available, sending the audit event record to a first audit subsystem associated with the first audit log, wherein the first audit subsystem performs writing the audit event record to the first audit log; and

if the first audit log is not available, sending the audit event record to a second audit subsystem associated with a second audit log of the plurality of audit logs, wherein the second audit subsystem performs writing the audit event record to the second audit log.

22. A computer-implemented method, comprising:

receiving a request to service an audit log from a secure partition of a requesting system, wherein the secure partition is isolated from a host operating system of the requesting system, the audit log comprises an audit event record of auditable events performed in the secure partition, and the audit log is isolated from the host operating system of the requesting system;

establishing a secure communication channel with the secure partition; and

servicing the audit log via the secure communication channel.