Managing a Network of Self-Encrypting Hard Drives

With high-profile data breaches making headlines regularly, organizations are carefully evaluating their options for protecting mobile data. For years, software full disk encryption, (FDE), has been the preferred means of addressing this threat. But widespread adoption has been hampered by the complexity and cost surrounding these software-based FDE deployments.

Figure 1. SED Architecture Block Diagram

Before exploring the integrated management of hardware encryption, it may be useful to step back and review the development of self-encrypting drives (SEDs). The first SEDs were made available in 2007 by Seagate Technology. Nearly three years later, most all hard drive vendors have developed their own versions, spurred by the passage of a single industry standard, Opal, published by the Trusted Computing Group in January 2009. Today, SEDs come in various form factors and speeds, including the first solid-state SED (offered by Samsung).

The growing presence of SEDs in the data protection market can be attributed to several drivers including:

  • Federal regulations increasingly require public disclosure in the event personally identifiable information has been mishandled;
  • Storage technology is getting faster (notably solid-state technology is altering expectations in terms of data throughput and responsiveness);
  • Growing awareness from IT that costs related to encryption encompass more than simply licenses; there’s significant expense related to management and integration, as well as the cost of acquisition.

Notably, there are significant technological differences between traditional software-based FDE and SEDs. With SEDs, the encryption keys are generated in the drive itself and access control/ authorization also takes place in the drive. The drive-embedded encryption executes below the partition table and below the file system.

Hardware-based self-encrypting drive technology enables “always embedded” key management, which, when managed properly, does not expose the encryption key outside the drive hardware. This creates a root of trust for storage and the encrypted data cannot be accessed unless the attacker has access to the drive hardware. This protected key management effectively creates multi-factor security for drive data. To access the data, both access credentials and the original drive hardware are required (i.e., something you know and something you own). In contrast, software-encrypted partitions can be copied and attacked offline (this becomes even easier if the keys are centrally stored and accessible through insider attack).

Encryption Schemes

Figure 2. ASCII Dump of Bitlocker MFT

To prevent data leakage and to ensure conformity with corporate governance practices, IT must have a means of effectively “wiping” sensitive data from a machine. With an always embedded key architecture, data can be cryptographically erased just by destroying the key. Traditional key management in software tends to archive keys outside the drive hardware in central repositories or in “blobs” (encrypted binary data). When keys exist outside the drive hardware, a cryptographic erase is insufficient (if an externally archived key is available, then the cryptographic erase process is reversible). This applies to all software-based encryption solutions, as copies of the encryption key are stored in blobs on the drive along with the data. These blobs can be copied from the drives and attacked offline, or used in conjunction with key loggers or insider attack to harvest data.

Another hallmark of self-encrypting drive security is access control and privilege authorization embedded in the hardware of the drive. In operation, this is similar, conceptually, to setting the door latch to “lock” before the door is closed. Once drive lock-mode is set, access is prohibited without proper credentials. With self-encrypting drives, there are no backdoors. Access control for administrators and users is completely independent of the host operating system (OS). In contrast, many software encryption solutions automatically grant access to anyone with valid Windows credentials. The new generation of self-encrypting drives feature tamper-resistant mechanisms that are completely independent of software or the host OS, such as the drives locking after five failed authentication attempts, requiring a power cycle of the machine. This slows down a brute force attack and makes it impractical to execute.

With self-encrypting drives, the encryption happens below the file system and below the partition table. Attackers therefore have no way to navigate around an encrypted partition of a self-encrypting drive; no master file table or tidy indexed blocks of encrypted data are visible — only a single expanse of almost random data from which no intelligence can be extracted by examining the raw media without the proper encryption key. By comparison, software-based encryption happens in the OS above the file system and the partition table. For example, when a Microsoft Bitlocker encrypted partition is examined, a modified master file table is visible. This enables the Bitlocker signature FVE-FS tag to be identified and used to locate the cryptographic blobs containing the Bitlocker encryption keys.

Hardware-embedded authentication and authorization enables exclusive ownership of the management rights for a specific drive. A remote server can set the drive administrator credentials when it initializes the drive security hardware. In this way, the server becomes the remote proxy owner of the drive; no other entity can modify the security settings of the drive hardware or enroll users. Centralized management with hardware-embedded root-of-trust for management ensures that the server management log establishes a complete record of all management transactions applied to each remote storage device. This exclusive ownership by a remote server is the foundation for forensic legitimacy. By contrast, the security settings of a software-based solution can be modified by any user with machine admin credential so-therefore, the integrity of the audit log cannot be assumed. As the importance of compliance increases, organizations will require storage devices that contain a hardware-embedded root-of-trust.

Harnessing Technology for Out-of-Band Management

Figure 3. AMT Management Tunnel From Firewall to SED

Embedding data protection in the drive hardware creates a natural layer between the data protection engine and the data protection management layer, enabling independent innovation above and below this layer. Wave Systems, which has developed remote management capabilities for managing self-encrypting drives, has successfully integrated these capabilities with Intel vProTM AMT technology, for advanced out-of-band management. Intel vProTM includes a protocol stack and management engine, which are embedded in the chipset hardware. Remote management commands can be encrypted on the server and sent directly to the Intel chipset. Capabilities also include “waking” clients that are not booted or those that have a corrupted OS. Benefits of the integration include the ability to:

  • Remotely manage clients that are powered down
  • Manage clients with a corrupted client OS
  • Implement real-time communication between a server and the self-encrypting drive pre-boot application

In addition, Wave has embedded a one-time password scheme for communication of all credentials. This adds protection against network replay attacks and insider attacks. The embedded vPro management engine can be programmed to register with a remote server and provide its IP coordinates, even when it is being served by a third party domain name system (DNS). The Intel advanced management technology (AMT) can be programmed to support multiple wireless profiles. Management settings for AMT are protected by both the vPro embedded authentication engine and the tamper-resistant features embedded in vPro. The integrated solution enables organizations to manage and audit data protection both inside and outside the firewall with immunity from network and OS-level attacks.

In addition to security, out-of-band connectivity provides secure real-time communication between the pre-boot at environment and a remote server. This can support a remote pre-boot enforcement of centralized policy. Applications could include policies that allow only drives to be unlocked when they are inside the firewall — outside the firewall, the drives are impenetrable and data is protected. In a similar fashion, out-of-band recovery and self-help can be implemented by intelligent central servers. This reduces costs for rescuing users who have lost or forgotten their drive access credentials.

As external collaboration and mobile computing continues to grow, IT must contend with open public networks, increasingly sophisticated attacks, and increased regulation. With the first generation of self-encrypting drives now on the market, new management tools are required for hardware-based security and Intel’s vPro technology offers promise for out-of-band management embedded in the chipset. Traditional security management for software encryption has evolved and been extended to provide ease-of-use. But this ease-of-use has come at a price: less security. Examples include Wake-On-LAN and auto-boot, which leave system access credentials in the client pre-boot area. Therefore, simply extending legacy solutions for managing SED technology isn’t the answer. Self-encrypting drives call for a management infrastructure that has been designed specifically to manage hardware-based security — without introducing legacy vulnerabilities.

This article was written by Aidan Herbert, Senior Product Manager, Wave Systems Corp. (Lee, MA). For more information, contact Mr. Herbert at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit http://info.hotims.com/28053-403 .