Download this article in .PDF format
This file type includes high-resolution graphics and schematics when applicable.
Solid-state disks (SSDs) have changed the face of our electronic world, giving us faster, longer-lasting, reliable storage for our mobile devices, laptops, desktop computers, and even servers. But while solid-state storage has provided a number of huge benefits over its rotating magnetic predecessors, ensuring strong data security has been difficult.
Encrypting or destroying sensitive information on hard drives was straightforward--locate the data and overwrite the bits. But because of the wear-leveling algorithms integral to modern SSDs, data remnants are often spread through a drive, making it very difficult to securely destroy sensitive information without erasing the whole drive.
However, SSDs now have a new trick up their sleeve. Hardware-based disk encryption is becoming a feature on an increasing number of consumer and industrial SSDs.
On these SSDs, data is always secured with Advanced Encryption Standard (AES) encryption. This happens transparently to the user, and unlike software-based disk encryption like BitLocker, there’s no performance penalty when using encrypted SSDs. That’s because the encryption is handled by a dedicated cryptoprocessor on the drive.
Hardware-Based Whole Disk Encryption
Encrypted SSDs not only operate at full speed without impacting system performance, but offer a number of advantages over software-based disk encryption. Security-wise, just like any other disk-encryption solution, encrypted SSDs perform transparent, complete encryption of all files including hidden and temporary files that may store sensitive information. However, the cryptographic hardware and encryption key is isolated from the host system, making the encryption process robust against attacks or viruses on the host system.
Authentication with encrypted SSDs happens pre-boot. All user space data, including the operating system, is completely inaccessible until the user is authenticated.
Sanitizing encrypted SSDs is fast and secure. On the other hand, sanitizing a conventional hard drive or SSD requires overwrite procedures that can take hours or days (and is impossible if the drive is malfunctioning), or physical destruction that could still leave data on the drive. On an encrypted SSD, though, it can take less than a second to change the encryption key (used to both encrypt and decrypt the data), rendering all data currently on the drive unreadable and for all intents and purposes, completely destroyed.
Unlike software-based encryption solutions, encrypted SSDs are OS-agnostic and can be used on Linux, Windows, OS-X or virtually any other operating system.
How Does Hardware-Based AES Disk Encryption Work?
Modern encrypted SSDs use a 128- or 256-bit AES algorithm along with two symmetric encryption keys (Fig. 1). The first key is the Encryption Key, used to encrypt all data stored on the drive. Assuming the drive uses AES-256 bit encryption, this key is a 256-bit number generated randomly and stored in encrypted format on a hidden area of the drive. The Encryption Key never leaves the device and is known only by the drive itself. Not even the drive manufacturer knows the value of the Encryption Key.
The second key is the Authorization Key, which is set by the user and controls access to the drive. If the Authorization Key is not set, for instance when the drive is first used, the SSD will appear to behave just like a normal unencrypted SSD. In fact, the data is still being encrypted at this point, but without an Authorization Key, the drive is unlocked and automatically decrypting read requests with the Encryption Key. Like the Encryption Key, the Authorization Key is never stored in plaintext, but rather only in an encrypted state.
When the Authorization Key is set on an OPAL 2.0-compliant SSD, a number of things happen: the Media Encryption Key is encrypted by the Authorziation Key, a cryptographic hash of the Authorization Key is stored on the drive, and the drive is set to be locked and prevented from being accessed the next time the machine is power cycled.
The next time the machine is booted up, the machine doesn’t see the normal master boot record (MBR). Instead, there’s just a small pre-boot image—the MBR shadow. This pre-boot area performs authentication and the user inputs his or her credentials, which are run through a Key Deriving Function to generate an Authorization Key. If the Authorization Key submitted by the user matches the one stored on the drive, the user is authenticated. The authenticated Authorization Key is then used to decrypt the Encryption Key and load it into the cryptoprocessing engine. At this point, the real MBR is also loaded so that the system can boot and operate normally.
Managing Encrypting SSDs
Depending on the specifications of the drive and host system, an encrypted SSD can be initialized, authenticated, and managed through either ATA security or TCG Opal 2.0 compatible software.
If supported, the simplest way to use an encrypted SSD is through ATA security using system BIOS. This is suitable for embedded and industrial systems, or single-user computers, and is as easy as setting the ATA password. Setting the ATA password will set the Authentication Key and enable authentication on an encrypted SSD. The ATA interface can also be used to issue a cryptographic erase—this is when the Encryption Key is updated, rendering all data on the drive unreadable.
TCG OPAL 2.0 software
Though ATA security is free and simple to use, it doesn’t take full advantage of OPAL 2.0-compliant SSDs, isn’t available on every motherboard, and even when available, it’s difficult to be sure of how secure the authentication process is without access to the BIOS code.
For stronger authentication, increased peace of mind, and much better management capability, a wide range of certified third-party encryption software and utilities designed to manage OPAL 2.0 devices is available.
OPAL 2.0, the latest version of the specification, accommodates block sizes appropriate for SSDs and LBA range alignment in order to minimize write amplification. Encrypted SSDs should be OPAL 2.0-compliant for optimal performance. They also need to be used with software that supports OPAL 2.0, since the specification is not backwards-compatible.
Besides setting the Authentication Key and allowing for cryptographic erases, OPAL drive management software allows for a 128-MB pre-boot environment to be loaded, providing sophisticated access control such as biometric, TPM, network, or even two-factor authentication.
Drives can be configured with multiple logic-block-address (LBA) ranges, each with its own access control (Fig. 2). Each LBA has its own Authentication Key and Encryption Key, and users will only be able to see and access the range specified for them.
Using appropriate software, OPAL 2.0-compliant drives can be centrally managed over a network, with remote initialization, range management, and data sanitization. With centralized control, a remote OPAL 2.0 SSD can be deployed without any restriction on the host operating system.
Encrypted SSDs that comply with both TCG OPAL 2.0 and IEEE 1667, such as Innodisk’s 3MG2-P, qualify as Microsoft eDrive compatible (Fig. 3). SSDs that are eDrive-compatible can be used with Microsoft BitLocker in Windows 8 Pro, Enterprise, RT, and Windows 2012 Professional. The drive then acts like a normal BitLocker-encrypted drive, but instead of the usual software-based encryption, encryption is done on the drive’s native hardware.
Limitations of Encrypted SSDs
As strong as the 256-bit AES encryption is on encrypted SSDs, it only protects data at rest, i.e., when the system is turned off. To protect data in flight, data-loss-prevention (DLP) techniques, use of secure communication protocols, and other security measures must be taken.
Nevertheless, even with these limitations, which are inherent to both software- and hardware-based disk-encryption techniques, encrypted SSDs provide a huge leap forward in data security by providing strong, easy-to-use, transparent encryption.
Looking for parts? Go to SourceESB.