The flood of worldwide laws and regulations regarding privacy and data protection, along with escalating penalties for breaches and violations, have made full-disk encryption a required capability in PCs. Once all the data on a disk drive has been encrypted, including the operating system, one of the technical challenges for full-disk encryption is how to provide a mechanism for authentication of authorized users before ‘unlocking’ the drive in order to boot the system and provide access to the user data.

Software-based full-disk encryption applications have been around for many years. Typically, software-based-encrypting drive solutions provide pre-boot authentication software, which modifies the master boot record and the operating system in order to gain control of the system at power up.

Authentication is performed by the PC before control is passed to the operating system. The authentication software then provides support for a range of authentication options such as passwords, biometrics and smart cards. Once authentication has taken place, the encryption key is made available to decrypt the disk drive and give control of the drive back to the operating system to boot.

Several of the challenges with this approach include the requirement to modify the core operating system and security exposures associated with a wide range of attacks aimed at capturing the authentication credentials, the encryption keys or modifying the pre-boot software to gain access.

Separate from the authentication challenges, software-based full-disk encryption faces traditional disadvantages like degrading the PC performance, administrative headaches for the IT personnel who must deploy and manage the software and manage encryption keys, and the complexities associated with the software working with core systems functions, other security applications, and systems tools and utilities.

Several years ago, the Trusted Computing Group–an open, industry standards organization engaged in creating security hardware specifications–tasked a work group comprised of the major disk drive companies and storage software vendors to create an open specification for adding encryption capabilities into the hardware of storage devices. The group also had to define a new approach for user authentication to the drives. In 2009, the organization published three specifications associated with self-encrypting drives. These include a specification for client drives (Opal Subsystem Class) a specification for data center drives (Enterprise SSC) and a drive interface specification. All now have been implemented in drives.

How self-encrypting drives work

The security model for the drive is very straightforward: when power is removed from the drive it is locked. When the user shuts down their system or a drive is removed, it will automatically lock.

How does this work? Encryption hardware is added to the drive controller, providing encryption/decryption of all user sectors of the drive. The drive operates at its full media speed, with no impact on throughput or performance. Encryption is always on and cannot be turned off by the user. The drive controller generates the encryption key internally; therefore, it never leaves the drive and thus does not need to be backed up, recovered, nor managed, unlike traditional software encryption. To erase the drive, an administrator merely deletes the encryption key, a process that takes less than one second and renders any data unavailable. The drive will automatically create a new encryption key and new data can be immediately written to the drive under the new key.

All current self-encrypting drives use AES 128 or 256-bit encryption keys using standard algorithms that are FIPS 197 certified. In the design of the cryptography, the secrets such as encryption keys, passwords, etc. are never held or stored in the clear. They are typically hashed, so if the drive is stolen, there is no way for the thief to get the secrets out of the drive. The only way to access data on the drive is to have the credentials to unlock it.

Authenticating users to self-encrypting drives

Self-encrypting drives have two modes of operation. The first is a standard ATA mode in which the drive functions as any standard drive, including the use of the ATA security commands for setting a user and a master password, assuming the PC BIOS has been enabled for that function. The passwords are set by going into the BIOS SETUP, turning on the hard drive password, and setting the passwords. This function has been generally available for many years and does not change for the ATA mode of self-encrypting drives; however, it is not standardized, is only for individual users, and has known security exposures.

The new self-encryption drives required a different approach to be highly secure, independent from the operating system, support all the authentication capabilities enabled by software encryption, and provide support for multiple users and administrators, each with their own unique credentials and unique authorized functions.

To achieve this, drives based on the new specifications provide secure areas of storage called Security Providers. These are not included within the user area of the drive and are intended for storing software and other secure information. Normal disk tools and utilities for formatting, erasing, and etc. cannot see nor can they make any changes to these protected areas.

This secure storage is fully protected from an access standpoint so that only ‘authorized’ software or parties can access it. The largest of these secure partitions is up to 128 megabyte and is designed to store a pre-boot operating system whose primary function is to provide device support and user interfaces for the various authentication devices in the platform, such as the keyboard, biometric sensors, and smart card readers.

Self-encrypting drives are shipped in the normal ATA mode; however, using management software designed to provide full life cycle services for self-encrypting drives, the user or enterprise can subsequently ‘initialize’ the drive in order to enable the advanced functions.

When a self-encrypting drive is initialized, the new advanced security functions defined by the Opal specification are activated in the firmware. The management software loads a pre-boot OS into the protected area, which becomes a ‘shadow’ or ‘alternate’ master boot record. Finally, users and administrators, identified by their normal domain/user ID in an enterprise directory, are assigned to the drive, along with their initial passwords. With Opal drives, depending on the vendor, you can have 4-24 users and 4-8 administrators assigned to each drive, with a range of defined capabilities.

For most users, the only functions they are allowed to perform on the drive are to authenticate for unlocking and changing their passwords. They cannot add other users nor disable drive locking. All appropriate security General Policy Objects, such as changing the pre-boot, adding users, or disabling drive locking requires an administrator. This level of drive control provides much better enforcement of policies for compliance assurance reporting. The management software makes setting up of self-encrypting drives easy and enables them to be integrated into the enterprise identity and access management systems. Many software programs for these self-encrypting drives also supply a centralized server management capability for IT control of remote drives in user machines.

Authentication in operation

When a user powers up the PC with an enabled self-encrypting drive, the self-encrypting drive firmware defaults to use the ‘Shadow’ Master Boot Record, which automatically loads the pre-boot OS into the system from the protected area on the drive. This is a highly secure solution, since alteration of the pre-boot OS is very difficult to do by any known attacks or hacks, and there are no other processes running in the system during this time, so key stroke loggers and other attacks are highly unlikely. The pre-boot OS guides the user through entering their credentials and provides for strongly authenticated, high quality assurance to unlock the drive.

Currently, self-encrypting drives only accept passwords for user authentication to the drives. However, these passwords can be up to 32 characters long and support the typical complexity approaches. In order to have multi-factor authentication to drives, the pre-boot operating system from the drive management software vendor must support the multi-factor capabilities in their software and/or the hardware features integrated into the PC platform by the manufacturer.

Moving forward, the drives will also support PKI certificates, but the support for biometrics, smart cards, etc. will remain in the pre-boot operating system. One PC maker, who has integrated support for both a full range of authentication devices and self-encrypting drives, provides an excellent implementation for multi-factor authentication to the drives. The PC has a hardware crypto vault for storing passwords in a security chip on the platform. Fingerprints are authenticated in hardware. Smart cards, both contact and contactless, are hardware supported in the platform, and the Trusted Platform Module (TPM) chip in the PC also protects credentials.

The management software shipped with the platform manages both the authentication devices and the self-encrypting drives. For multi-factor authentication, once a user has successfully entered their tokens, fingerprints, PINs, etc. and has been authenticated in the pre-boot firmware, a drive authentication password is released from the crypto vault and securely sent to the self-encrypting drive.

The drive, since it does not store the passwords–only a hash of the passwords–authenticates a hash of the password and, if successful, uses this to decrypt the media encryption key, thus ‘unlocking’ the drive. The drive will immediately begin decrypting the Master Boot Record, OS, and user data and the system will boot normally.

The authentication process, done in hardware, is very fast and normally takes only several seconds to unlock the drive and continue on to booting the system in a normal fashion. Since encryption happens at the hardware level, it is completely transparent to all the rest of the system and secure. As an option, the strong authentication transaction can be passed from the protected self-encrypting drive and can then be used for single sign-on and access to other key resources in the enterprise network or on the Internet.

The future of authentication with self-encrypting drives

With this new ability to achieve a highly secure multi-factor authentication in the PC at the edge of the network, completely independent from the operating system and protected from attacks, there are some strategic security options. The self-encrypting drive and authentication provide a strong ‘root of trust’ in order to initialize other highly trusted environments and applications. Virtualization and multi-core processors are enabling end users to have virtual machines for specific applications, including ‘trusted virtual machines’ which could be used for secure online banking, accessing cloud services, and fully authenticated access to corporate networks. Strong authentication with self-encrypting drives has the potential to dramatically improve the overall security in end user devices.

---

The Trusted Platform Module (TPM)

The Trusted Platform Module, or TPM, is a microcontroller or other integrated circuitry that securely stores passwords, digital keys and certificates that can provide unique identification. It is based on specifications created by the Trusted Computing Group and versions are available from a number of semiconductor vendors. The TPM handles cryptographic operations such as asymmetric key generation, asymmetric encryption/decryption, hashing and random number generation.

Some 200 million PCs, servers and embedded systems include the TPM, and many vendors provide software that enables its use. These packages support multi-factor authentication, single sign-on, password management and other functions.

As part of its High Assurance Platform program, the National Security Agency uses the TPM in a virtualized approach to run multiple secure environments. Almost all computers acquired by the Department of Defense since July 2007 are required to have a TPM.

In authentication, the TPM plays a key role, where it can provide “something you have.” An additional factor such as a PIN or password can be added for “something you know.” The TPM has proven to be more secure and provide a lower cost of ownership than software-based certificates, tokens and smart cards. Plus it is the only token that supports both strong user and machine authentication. The TPM meets most enterprise requirements for multi-factor authentication for remote access. Wireless access can be protected with the TPM, where it securely identifies a user or machine and automatically integrates with the 802.1x authentication framework.

The TPM also can determine changes to the system prior to boot-up, which means root kits and other malware can be detected and action taken before the system is booted and connected to a network. During the boot process, the TPM measures or hashes all the critical software and firmware components, including the BIOS, boot loader, and operating system kernel, before they are loaded. By making these measurements before the software runs and storing them on the TPM, the measurements are isolated and secure from subsequent modification attempts. When the PC connects to the network, the stored measurements are sent to the server, checked against the server’s list of acceptable configurations, and quarantined as an infected endpoint if a non-match occurs.

TPM information can be found at the organization’s website, http://www.trustedcomputinggroup.org/developers/trusted_platform_module.