Intel® vPro™ Technology

Storage Protection with Intel® Anti-Theft Technology - Data Protection (Intel® AT-d)

The Intel Data-at-Rest Solution

Intel® Anti-Theft Technology - Data Protection (Intel® AT-d), employs a storage controller encryption technique to encrypt Serial Advanced Technology Attachment (SATA) data streams. Intel AT-d is part of a suite of technologies under the Intel® vPro™ brand that includes firmware for improved management, network connectivity, and system performance. Intel AT-d leverages the manageability features of the Intel® Management Engine (Intel® ME) to ameliorate many of the challenges inherent in the protection of DAR.

System Overview

Figure 5: Intel® Anti-Theft Technology - Data Protection hardware architecture
click image for larger view

Figure 5 shows the components of the chipset that implement DAR protection. The Crypto Services Block (CSB) is a hardware implementation of the Advanced Encryption Standard (AES) and it supports key sizes of 128 and 256 bits. The Virtualization Engine (VE) is comprised of a general-purpose controller that performs SATA command decoding and other accelerated operations by using dedicated silicon. The Intel ME controls the behavior of the VE and CSB by configuring policies and keys. The Intel ME also collects audit events, manages user authentication, and interfaces with enterprise services. The integrity of the firmware for both the Intel ME and VE is ensured by means of a digital signature before it is stored on the Serial Peripheral Interface (SPI) flash memory. User Access Control Lists (ACL) are encrypted and stored in a data region of SPI flash memory. A portion of the SATA device is reserved for DAR metadata that contains the Disk Encryption Key (DEK) that encrypts data on the disk. Data can be cached for performance improvements on platforms containing Nonvolatile Memory (NVM). Data stored in NVM persist after power is removed from the system; hence, they must be encrypted to be protected from theft. When the platform is fully powered, a portion of DRAM, known as ME-UMA, is available for use by Intel ME. The host OS is not able to access ME-UMA memory, in general, because of a memory isolation mechanism that is configured by the Basic Input Output System (BIOS) and then locked before the OS runs.

Encryption is applied to a data write operation as follows:

1. The AHCI driver issues a data write command to the VE.
2. The VE decodes the command and identifies the data portions to the SATA controller.
3. The SATA controller routes data on the fly through CSB, which encrypts the data by using the key previously supplied by the Intel ME.
4. The CSB returns the data to the SATA controller for transmission across the SATA interface to the storage device.

A read command is the reverse of a write command, but with decryption. Before any encryption or decryption can be performed, the Intel ME must insert the DEK into a memory register in the CSB. The CSB contains registers for up to six encrypted SATA devices. When storage devices are enumerated, the VE checks for the existence of Intel AT-d metadata on the disk. If found, the metadata are returned to the Intel ME to be decrypted. The DEK is wrapped (further encrypted) by a key that is derived from two values dynamically obtained. The first value is a passphrase obtained from a user. The second value is a chipset key that was embedded in hardware at the time of manufacture. Each chipset key is unique to a specific platform, but the key cannot be read externally. The passphrase and chipset key are supplied to a Public-Key Cryptographic Standard (PKCS#5) key derivation function that outputs the DEK wrapping key. Because the wrapping key is derived each time the system is powered up, a thief must know the user passphrase and have access to the chipset key in order to obtain the DEK.

Storage devices protected with Intel AT-d are therefore bound to the platform that encrypted the data. This prevents an attacker from putting the drive into another platform on which an attack tool kit could perform a variety of cracking techniques.

Audits are triggered whenever a function is performed that could affect compliance with privacy regulations. Auditable events include enabling/disabling encryption, changing encryption keys, modifying key strengths, successful and failed user log-on attempts, key recovery, and remote unlock operations.

Intel AT-d is compatible with Intel® Matrix Storage Technology implementation of the Redundant Array of Inexpensive Drives (RAID). The RAID abstraction is applied after the Intel ME unlocks the drives participating in the RAID array.

All data on an Intel AT-d protected drive are encrypted, except for the Intel ME metadata and pre-boot authentication (PBA) metadata areas (see Figure 15), which remain unencrypted. This includes Master Boot Record (MBR), RAID metadata, and OS and user data. Fully encrypting the drive protects sensitive data included in paging and configuration files, and it prevents offline attacker manipulation of system files by a toolkit.

Fully encrypting the drive also presents challenges to IT organizations. An encrypted MBR prevents recovery operating systems from loading until the disk is unlocked. Encrypted RAID metadata can prevent initialization of the RAID array as well. User authentication, therefore, must occur before any pre-boot service that requires drive access.

User authentication is facilitated by host software in the pre-boot environment. A pre-boot authentication module interfaces with users to obtain passphrase or other credentials that are given to the Intel ME for validation, evidenced by successful unwrapping of the DEK.

The Extensible Firmware Interface (EFI)[7], the next generation of system firmware, supports driver dependency declarations, useful for staging system bring-up actions to account for DAR encryption constraints. The EFI framework supports many other features that make it easier for vendors of multifactor authentication components to work together to provide a rich and robust pre-boot authentication solution. This allows vendors to specialize by using best-of-breed capabilities in their products.

Crypto Services Block
The crypto services block (CSB) implements in silicon the AES algorithm using the LRW mode (see Figure 6 and [8] for more on this mode). There are three cryptographic engines that can be multiplexed across a variable number of SATA ports.

Figure 6: Crypto Services Block
click image for larger view

There are six key slot registers that store disk encryption keys for fast access from any of the three crypto engines. Key slots are populated by the Intel ME at platform initialization and when new drives are detected. An Engine Arbitration module ensures the data input stream, encryption key, encryption engine, and the data output device are scheduled before processing write operations.

Each crypto engine block operates at or near line rates to ensure that it doesn’t introduce any latency. This eliminates the need to multiplex a single stream over multiple crypto engines.

Virtualization Engine
Data enters the VE over the Desktop Management Interface (DME) and a virtual host controller such as the AHCI, which is used for SATA devices. The VE can support multiple virtual host controllers, but typically only a single virtual AHCI is usually needed.

The VE itself is an ARC* International 32-bit microcontroller that runs a ThreadX* real-time OS by using Express Logic* that runs firmware developed by Intel. The VE uses on-chip SRAM and can access system DRAM that is isolated from host CPU cores. SATA command-decode operations and other functions can be performed by dedicated silicon designed to accelerate command processing.

The CSB is accessed by the SATA Controller as data packets are available for encryption or decryption. The encrypted packets (assuming write operations) are then routed to the SATA interface by the physical host controller. The SATA storage device is unaware that data are encrypted; therefore, in theory, any SATA-compliant storage device could support Intel AT-d encryption (see Figure 7).

Figure 7: Virtualization Engine
click image for larger view

Intel® Management Engine
Much like the VE, the Intel® ME (see Figure 8) is an ARC International, 32-bit microcontroller that runs the ThreadX, real-time OS. Firmware developed by Intel implements key management, access control, and other support. The Intel ME can use both on-chip SRAM and DRAM that is isolated from the host CPU. Persistent data are stored in flash memory accessible by the SPI bus. All Intel AT-d metadata stored in SPI flash and on the drive are encrypted by using a platform container key (PCK) that uses counter mode AES (AES-CTR) encryption (see [9] for more information on CTR).

Figure 8: Intel® Management Engine
click image for larger view

The Intel ME can control aspects of VE operation directly over the Intel ME Command Interface (MECI), which is an internal bus. The Intel ME may also access on-board networking interface devices during low-power states, such as Sleep mode, in addition to normal operation. The Intel ME shares network resources with the host OS, but the host is unaware of this unless special monitoring tools are used. The HECI is used by host drivers to communicate directly with the Intel ME.

Figure 9: Intel® Management Engine common services
click image for larger view

The Intel ME firmware is modular, that is, core capabilities function independently of others, and new capabilities may be easily added.

Functionality that is commonly used by multiple capabilities is called Intel ME Common Services (CS) and consists of three major parts: Networking Services, Security Services, and Provisioning Services (see Figure 9).

Networking services comprise a Transmission Transport Protocol/Internet Protocol (TCP/IP) stack, Transport Layer Security (TLS), Hypertext Transport Protocol (HTTP), Simple Object Access Protocol (SOAP), Web Services for Management (WS-MAN), and a host-based TLS interface called the Intel Local Manageability Service (LMS).

The TCP/IP stack supports either IPv4 or IPv6, depending on which technology generation is running. For IPv4, the host OS will share the same network address with the Intel ME. For IPv6, the Intel ME has its own IP address that is not shared with the host. We explore in more detail the services needed to support DAR encryption in the "Intel® Anti-Theft Technology - Data Protection Support Services" section of this article.

Security services provided by the Intel ME CS include the following:

• User authentication consisting of both HTTP Digest and Kerberos [10]
• Domain authorization using Microsoft Active Directory*
• Secure time
• Auditing

Provisioning services support two deployment modes: zero touch and one touch. With zero touch, deployment certificate anchor keys are embedded in the firmware, allowing well-known certificate authority keys to be used to validate IT credentials that can then be used to take ownership of the platform. One touch mode configures organizational certificates, symmetric keys, and trusted hosts that may be used to complete setup and deployment tasks remotely.

Intel At-d ME firmware implements the Storage Encryption Service (SES) that includes management of key storage hierarchy, drive migration, setup, configuration, drive conversion, user authentication, and access to devices.

Key Hierarchy and Management
Intel AT-d key hierarchy is a three-tiered hierarchy that uses either derived keys or externally escrowed keys to wrap a device group key (DGK) that in turn wraps one or more device encryption keys (DEK), one per encrypted device.

Figure 10: User key hierarchy
click image for larger view

The user key hierarchy is shown in Figure 10. Both the DGK and DEK are generated on the platform by using both a pseudo-random number generator (PRNG) and a true random number generator (TRNG) to seed the PRNG. The key hierarchy is stored as metadata in both SPI flash memory and the storage device.

Table 1: Key generation formulas

Key	Generation Formula
DEK	PRNG(TRNG() = seed)
DGK	PRNG(TRNG() = seed)
Fuse Key	Manufacturer blown fuses
PCK	HMACSHA256(FuseKey, Intel® Management Engine fuses, key-string)
User Keys	HMACSHA256(PCK, rand, PKCS#5(name, pin, string))
Security Questions (SQ) Keys	HMACSHA256(PCK, rand, PKCS#5(name, SHA256(answer1, answer2, answer3)))
RCK	PKCS#5(recovery token)

User keys are derived dynamically from user-supplied credentials. Up to six local accounts are supported. The PKCS#5 key derivation function combines user name, password, and a salt-string that is hashed, by using SHA-256 with the platform’s unique fuse key to produce the wrapping key. The fuse key has 256-bits equivalent entropy to counter brute force cryptographic attacks.

A variant form of the user-derived key is based on the familiar authentication method of combining the answers to three security questions by using SHA-256 to create a value that is substituted for the password value described earlier.

For scenarios in which an administrative console is used to remotely unlock the drives, a random number is generated and combined with the fuse key value to produce a remote access token that wraps the DGK.

Each principal wraps a copy of the DGK so as to avoid requiring a combination of principals to be present before access is granted.

Figure 11: Recovery key hierarchy
click image for larger view

A recovery token may be derived via PKCS#5 of a migration passphrase or it may be a random number generated by the recovery service. The migration token is used to wrap a Recovery Key (RCK) that in turn wraps the DEKs for each device (see Figure 11). The RCK can be random number generated by the recovery service or derived from the recovery token.

The generation of the RCK does not incorporate the fuse key value in order to facilitate cross-platform migrations. The migration token is stored safely in a key recovery server or other secure storage. Should drives require migration to a different platform, the RCK can be used to obtain copies of DEKs that are not bound to the old platform.

Access Control
Access to disks is controlled at the platform level, meaning all AT-d protected disks are made accessible when a user successfully authenticates. Finer-grain access control is possible, but it requires managing additional DGK keys. As the name implies, each DGK key is a member of a different group. By dividing drives into groups and wrapping their DEKs with the DGK keys, respectively, it would be possible to restrict access based on the user’s group affiliation.

Access to disks should be local, remote, and unattended. In local access, Advanced Technology Attachment (ATA) commands are blocked by the VE before an authorized user has logged on. When a successful logon occurs, the Intel ME notifies the VE of the status change; then the VE permits access (see Figure 12).

Figure 12: Local access control enforcement
click image for larger view

Remote access control is similar to local control except the remote user must be authenticated by the Intel ME by using administrative credentials. Credentials could be in the form of a Kerberos ticket or an X.509 certificate. Authorization data in the credentials may also constrain the actions of the remote user, further preventing access. The remote user must also present a remote access token (see Figure 10) to the Intel ME so that the Intel ME can unwrap keys.

Unattended access is sometimes desired if the system is set to automatically reboot after a power failure or other event. The BIOS and Trusted Platform Module (TPM)[11], or other similar secure storage device, are required to support this scenario. The TPM is used to protect an unattended access PIN that is stored locally (see Figure 13). The BIOS will calculate system state and extend TPM configuration registers during reboot. If the system state matches the system state expected by the TPM, then the PIN is released. BIOS can supply the password to the Intel ME as if in the local access scenario (see Figure 10).

Figure 13: Unattended Unlock with TPM
click image for larger view

If unattended access is required and an OS is stolen, it may be possible for encrypted drive contents to be read. Therefore, careful consideration should be given to this risk, before a system is configured for unattended access.

Many hard drives support drive locking by using ATA security commands. Locking the drive does not protect data from determined thieves; however, it does prevent casual data snooping. A locked drive also prevents the VE from accessing the device as the VE cannot completely initialize the device when it is locked. The VE does not have enough information to expose the device to the BIOS, without knowing the password. However, if the device remains hidden, the BIOS isn’t programmed to issue the ATA security command to unlock the device (see Figure 14).

Figure 14: ATA Security Drive Unlock with Virtualization Engine
click image for larger view

If user authentication occurs very early in pre-boot, even before drive identification, then user supplied Hard Disk Drive (HDD) passwords can be used to unlock drives transparently.

Drive Geometry
The VE virtualizes storage devices, so that multiple virtual drive partitions can be recognized. The vast majority of Intel AT-d platforms use a single virtual HDD partition (see Figure 15).

Contained within the first virtual HDD are all the traditional drive geometry elements. Beginning at Linear Block Address (LBA) zero, we have the Master Boot Record (MBR). This is followed by the drive data, such as the OS files and user files. Some systems have hidden partitions that may be used by BIOS or other system utilities. The Host Protected Area (HPA) can be used to store an emergency recovery OS (ROS), a multimedia utility, diagnostics utilities, or other programs. Systems with Intel Matrix Storage Technology subsystems that implement RAID place RAID metadata at the end of the virtual drive. By doing this, the RAID optional ROM can easily locate metadata at system initialization.

There is a single DEK for the drive that spans each virtual HDD, resulting in all virtual HDDs being encrypted with the same key.

The Virtual Drive Definition (VDD) data is placed at the end of the physical drive, LBA-n. VDD data contain drive geometry, marking the beginning and end of each virtual HDD. The VDD also identifies the start and end locations of the Intel ME metadata area. The VDD and Intel ME metadata are not encrypted by Intel AT-d. However, the contents of these areas are protected by the VE and Intel ME.

The Intel ME metadata consists of an AHCI file system block, Intel AT-d metadata, PBA code, and PBA metadata. The AHCI file system is used by an Intel ME firmware storage driver. Intel AT-d metadata contains the wrapped DEK, device configuration data, drive conversion status information, and the drive migration package. The migration package also contains a copy of the DEK wrapped with the RCK. Finally, Intel ME metadata contains PBA executables and a storage area.

Access to the PBA area is permitted via the VE by using the VE Command Interface (VECI), or via the Intel ME by using the Intel AT-d Host Command Interface (DHCI); which uses HECI. The VE can ensure that access requests outside the PBA ranges are prevented given that PBA code executes on the host processor.

Figure 15: Virtualization Engine drive geometry
click image for larger view

A challenging situation may arise when the HPA is used to store a backup copy of the BIOS, or when it is used to store BIOS extensions—and the HPA is encrypted. During pre-boot, before the disk has been unlocked, such features are unavailable.

The VE can expose the PBA data area to the BIOS for storage of a backup BIOS image or, in the case of Extensible Firmware Interface (EFI) BIOS, it can store EFI drivers that do not fit into the system flash memory. To accomplish this, the BIOS boot block or other BIOS drivers must recognize when the VE is accessing PBA data, versus accessing a typical hard drive. Two options exist for this scenario: either the BIOS will maintain two interfaces, one for each storage area, or the VE switches context underneath the AHCI interface when the drives are unlocked. BIOS may yet require a separate storage interface for PBA data, after drive unlock, if the BIOS need to access both areas of the drive simultaneously.

Figure 16 shows a backup EFI partition table located at the end of the drive, in the Intel ME metadata, that can be used to locate an unencrypted EFI partition (n) and an encrypted partition (x). Partition (n) is used before drives are unlocked for BIOS recovery, critical pre-boot authentication drivers, and any other BIOS code that must execute prior to the drive unlock event. Subsequent to drive unlock, partition (x) is available for EFI use.

Since EFI Partition (n) and the backup EFI partition table are located within the Intel ME metadata region, the BIOS must use a block I/O driver that is aware of drive virtualization, and software must be aware of the content stored in EFI Partition (n).

Figure 16: Virtualization Engine drive geometry with EFI partition
click image for larger view

Drive Migration
Each encrypted drive contains a copy of a migration package that is used to move the drive to another platform. Recall that user ACLs wrap DEK by using keys that are bound to a particular platform’s fuse key. The migration package, however, is not wrapped with a fuse key derivative. An escrowed key, also called the Migration Token (MT), is used instead. The MT can be stored by a key management service or simply in a personal storage device.

The Intel ME performs drive migration by doing the following operations:

• Generates RCK by using an MT for the previous platform.
• Decrypts the migration package.
• Reads the device configuration profile and DEK.
• Creates a migration blob for the new platform by using a new RCK.

Drives can be migrated between Intel AT-d platforms easily. Migration to other platforms requires an extra step that copies data to an unencrypted drive or partition.

Setup and Configuration
Before Intel AT-d can be used, Intel AT-d metadata must be instantiated and populated on the storage device and Intel AT-d platform flash. Device metadata partitioning is best created during manufacturing so that RAID metadata or user data is in the right place and does not have to be relocated. If the device metadata aren’t partitioned during manufacturing, these data might be allocated to the end of the drive where Intel ME metadata need to be located. Platform manufacturers can also configure Intel ME CS for zero-touch provisioning and remote enrollment of local users and administrators.

Intel AT-d can be enabled by an administrator through the Intel® Management Engine BIOS Extension (Intel® MEBX) utility in which user accounts and devices are configured for use. The first user created is a local administrator. The local administrator account is authorized to configure security policies, device recovery and migration, and user management. User accounts are also created with default credentials that a user can change upon first use.

If the drive had been previously in use and contains cleartext data, these data are converted (encrypted) in the background. The data conversion process is driven by the Intel ME. A systematic walk through each storage block on the device is read, encrypted, and rewritten over the cleartext. Flash memory storage devices require an additional step that clears blocks relocated by memory wear, leveling algorithms. Data conversion occurs in the background so users can continue working. The conversion algorithm is fault tolerant, so it will survive power failures.

The Intel ME performs data conversion operations. It does not have access to partition tables or file allocation tables (FAT) that may be helpful in distinguishing between data blocks and unallocated blocks; therefore, much of the conversion time may actually be spent encrypting empty blocks. Computers that don’t have encryption enabled may have unallocated blocks containing deleted files that could be viewed by using data recovery tools. Therefore, it may not be safe to use drives in environments where there is a risk of theft or loss until data conversion has completed.

Pre-boot Authentication
User authentication is a prerequisite for Intel AT-d drive unlock. Initialization of services, such as RAID, that can contain user data in metadata areas, must be encrypted. Since much of RAID initialization occurs in pre-boot, user authentication must also occur in pre-boot. In Figure 17, an abbreviated sequence of BIOS initialization steps is shown. Following PCI device enumeration and before RAID option ROM initialization, Intel AT-d with PBA option ROM runs and the user is prompted for log-on information.

Figure 17: Legacy BIOS pre-boot authentication architecture
click image for larger view

The popularity of multifactor authentication is increasing because of its improved security properties and improved usability. Usually, the integration of multifactor authentication into pre-boot authentication must interface with several different authentication devices that are connected over a variety of I/O buses, therefore creating a need for a rich PBA environment. Version 2.2 of the EFI environment defines a rich PBA environment (see Figure 18). Each authentication device is abstracted through a credential-provider interface; other modules that abstract user identity and user profiles also exist. These, combined with drivers for accessing Intel AT-d services contained in Intel ME, offer tremendous flexibility in enabling multiple vendors, specializing in different aspects of pre-boot authentication, to create a compelling full-featured PBA application on top of an EFI framework.

Figure 18: EFI pre-boot authentication architecture
click image for larger view

Enterprise users may value an extensible pre-boot authentication environment because of the prospect of integrating domain authentication and single-sign-on. Many enterprises deploy Microsoft Active Directory for centralized user management. Linking user identity management for multifactor authentication with Kerberos domain authentication has desirable security properties, especially if deployment costs can be minimized.

Intel AT-d drive unlock that uses enterprise domain authentication has an added security advantage: existing IT procedures for managing user accounts also extend to local drive access, independent of OS version or type, something that challenges IT departments trying to deploy data-protection policies uniformly.

Performance Considerations
The benefit of improved DAR management through Intel ME and VE has a small but measurable impact on data throughput performance. Although data encryption and SATA packet manipulation can be performed nearly at line rates, they are not instantaneous. Short latencies are introduced to roundtrip I/O operations, where roundtrip refers to the time the I/O operation enters the host driver queue until the completed operation returns back to the host driver. For sequential block operations, VE latency is added to HDD latency (see Figure 19).

Figure 19: Single device I/O latency with Virtualization Engine
click image for larger view

Multi-threaded I/O operations can be performed by using a RAID configuration. Block (n) processing can begin before Block (0) is completed by the HDD, which improves overall I/O latency significantly. However, the greatest opportunity for improving I/O performance rests with improving storage devices. The use of Solid State Devices (SSD) can dramatically improve performance, especially for small transfer sizes. The use of SSDs in a RAID array dramatically improves transfer rates for both large and small transfer sizes.

Data conversion performance is constrained by two factors: Intel ME horsepower and background host I/O activity. The ARC microcontroller operates at much slower speeds than typical host CPUs. Data conversion on the Intel ME is single-threaded, and it may be interrupted by higher-priority Intel ME tasks. Host I/O activity takes priority over data conversion; therefore, data conversion rates may vary.

Back to Top