.jpg)
As data becomes ever more mobile there's an increased risk that it can fall into the wrong hands. And, while there are many technologies to try and prevent this from happening, or tracking a device down if it's lost or stolen, the ultimate solution to data security is preventing it leaving the storage device in the first place.
Self-encrypting drives (SED), as the name implies, encrypt data at the level of storage. But it's more than just encryption -- after all, there are any number of tools to encrypt data both in transit and at rest for all the major operating systems, not to mention endpoint management solutions. The problem, however, with any software-based tool is that no matter how secure the operating system or the software, there's still a possibility for data loss -- as long as there's a program running resident in memory, it's vulnerable to be exploited.
Which is why the key selling point for self-encrypting drives isn't just that they encrypt data, but that it's carried out in the firmware of the drive. The encryption-key is kept on-chip, making it nigh impossible for it to be intercepted and thus allow an intruder to gain access to the data on the drive.
Self-encrypting drives aren't new -- Seagate released the first laptop hard drive with built-in encryption in 2007 -- but their adoption is only now starting to become widespread, in part thanks to higher exposure for Microsoft's eDrive format with Windows 8.1 Pro. This allows BitLocker -- which itself sports the ability to encrypt volumes or entire drives on the fly -- to utilise the hardware features of an SED over its own software-based encryption.
But eDrive is just Microsoft's implementation using BitLocker for SEDs, there are a number endpoint and management suites that also support SEDs. However just because a drive provides hardware-based encryption doesn't mean it's going to work out for the box for you -- there are both Opal 1.0 and Opal 2.0 compliant drives on the market as well as FIPS-certified products and some management packages may only work with a subset of drives, so it's important to research the products you want to use will play well together before investing in SEDs.
But first it helps to understand how self-encrypting drives work.
Securing security
At its core, an SED utilises two keys: the Media Encryption Key (MEK) and the Key Encryption Key (KEK). The MEK is set by a random number process in the firmware when the drive is made, that not even the manufacturer is aware of, and is used to encrypt and decrypt data on the fly to the storage medium (be that spinning-disk hard disk platters or the re-writeable memory in SSDs). Importantly, encryption is always on -- the firmware is always using the key to encrypt and decrypt data right from the moment it's used, even if you choose to use the drive without 'enabling' the encryption.
The KEK is used to encrypt the MEK, and can be supplied by the user as a password to access the drive, or as part of sign-on authentication (locally, or over a network etc.) With the KEK set, the drive will automatically enter a locked state when it's powered down, and remain that way until the correct password is entered when the machine next boots. Without the correct password, it remains inaccessible. This is different to a lock via the ATA command set (see 'What about ATA security?'), but is functionally equivalent -- the drive is unusable without entering the correct password to decrypt the MEK.
Data on the drive is encrypted using 128-bit or 256-bit AES depending on the make and model, and the KEK is also encrypted using at least 128-bit AES, from which a cryptographic hash is stored on a special pre-boot portion of the drive which is set read-only. When a system starts up and attempts to boot from the drive, the small bootable environment loads and prompts the user for the a password. The hash of the supplied key is compared to the hash of the KEK and, if correct, the MEK is decrypted within the firmware of the drive. At this point the main volume becomes visible and the computer can boot the MBR and load the operating system as per normal.
This has a number of advantages over traditional software-based full- or part-disk encryption for hard drives. The MBR isn't typically encrypted with software solutions allowing the structure of the drive to be determined, aiding in any attempts to access its data. Additionally, typical encryption suites still require software to be resident in memory, making it possible for bugs or flaws to be exploited to discover the encryption key. Finally, secure-wiping a disk can take many hours or even days for large volumes, but an SED can be secure-wiped in an instant: simply tell the drive to regenerate a new MEK, and all data currently on the drive becomes unreadable with no way to determine the original encryption key.
In the instance a pre-boot environment is not created the drive is still always encrypting anyway -- it's simply open to be read by any system the drive is plugged in to. Hence, to take advantage of an SED's hardware-based encryption to secure the drive's contents, you still need special software to create a pre-boot environment and manage the hardware encryption features.
What's in a name?
Read more: Pervasive technologies and its implication on security
When it comes to Opal, not a lot. Unlike many titles found in computing, Opal is not an acronym.
The Trusted Computing Group TCG comprises within it the Storage Work Group, which in turn comprises stakeholders in the storage industry working to set standards and practices for Trusted Storage, where Trusted Storage is defined as techniques and methodologies to allow users to store data with protection against theft or loss.
The working group is responsible for defining the Trusted Storage Architecture Core Specification within which exist a number of Security Subsystem Classes. These SSCs provide for various devices or products to be compliant without supporting the whole core specification where it is not needed.
So where does Opal fit in? According to the TCG when the working group started work on the SSCs, it named the various standards based on semi-precious stones. The Jade SSC defines the requirements for fixed-storage devices in high performance storage systems, typically servers. A storage device conforming to this standard is likely to be large and support interfaces like SAS. Opal defines much of the same requirements but focuses on products used in end-user devices such as tablets, laptops and desktops. Jade was later re-named to Enterprise, but Opal retained its moniker.
Functionally Enterprise and Opal are much the same, with perhaps the biggest difference being that Opal defines the use of the pre-boot authentication mechanism stored on the drive, which is absent in the Enterprise SSC. This has the the largest impact with regards to SEDs being used as boot drives for devices in the hands of employees, such desktops and mobile devices including notebooks and tablets.
Enabling an SED
So how do you prepare a system to use an SED? Unfortunately this is where some of the bling from SEDs wears off. In order to take advantage of the in-built hardware encryption, whatever software package you use to manage the drive needs to be compatible with the level of security it supports. And, because SEDs have evolved over the years with different manufacturers before standardising with the TCG (Trusted Computing Group), you may find there are various levels of support among management suites.
A prime example is Microsoft's own BitLocker. BitLocker is attractive because it's already part of Windows and can interface with various authentication and endpoint management tools. But it only works with SEDs that support the more recent Opal 2.0 standard (which are only now seeing mainstream release) and are IEEE 1667 compliant (the standard that defines restricting access to authenticated devices only). It also requires a motherboard with ideally a hardware TPM (Trusted Computing Module), a UEFI (Unified Extensible Firmware Interface) BIOS that must be UEFI 2.3.1 or later, have its CSM (Compatibility Support Module) disabled, and UEFI configured for boot mode. And (phew!) the drive must be uninitialised. If the drive has been previously partitioned, clearing these partitions is not enough -- the drive needs to be reset using the Clean command in Diskpart.
If you get all these silicon ducks in a row, you can use BitLocker with an SED. And, when you do, it kinda just works. BitLocker operates just like it normally does -- whether it's enabled during the OS install or later toggled for a particular drive -- only it's using the SED's hardware-based encryption. This is best seen, for example, when using an SED as a data drive and converting a disk that already has data on it. Doing so with Bitcloker's own software encryption can take many hours as data on the drive is read, encrypted, and written back. With an SED, however, converting the drive is instantaneous (remembering the data is already encrypted).
It's important to note that while some standards are designed to be backward compatible, this is not the case with TCG Opal. The latest version 2.0 has some features that are not supported with 1.0, and your choice of management or authentication software may only work with one version of the standard. For this reason it's important to research both the endpoint product you want for managing user authentication as well as the drives themselves to ensure they'll work together. And, further, any other hardware requirements (motherboard BIOS, UEFI configuration) that both drive and software require, as you may discover you need a very specific hardware chain to take full advantage of the SED.
Other than this, software designed with SEDs in mind apart from Microsoft's BitLocker include Wave's Embassy Remote Administration Server, Winmagic SecureDoc, Softex SecureDrive, and AsoluteSoftware Secure Drive among others. SEDs are also well supported by major anti-virus vendors McAfee, Symantec, Sophos, and TrendMicro, giving you lots of options for how SEDs can integrate into your current hardware and software deployments.
Typically these suites will allow you to remotely manage assets with SEDs including toggling the encryption key, setting up sign-on and authentication for users, logging of actions related to SEDs (including for example if encryption is disabled, or password changed), and standard asset management functions. Most of will utilise their own pre-boot environment installed on an SED at initialisation, as well as provide a means for users to recover their password with IT support should they forget it (which is somewhat critical considering that without a recovery mechanism, the loss of a password also means the loss of all data on the drive, since it's encrypted).
Ideally, a good product will allow you to set up a synchronised password prompt for the user that first unlocks the drive in the pre-boot environment then, once Windows has loaded, passes this on as the user's logon password as well, saving them the hassle of entering the same password twice (or two different passwords). Done well the integration of an SED to a system can be seamless, making the transition painless for users while adding a whole new layer of data security for the machines managed by your team.
And, should a computer be lost or stolen, the data will be inaccessible. Even removing it and plugging into another system, the core OS and user directory partitions will be encrypted and unreadable.
What about ATA security?
Part of the ATA (Advanced Technology Attachment) specification, which defines how storage devices like hard drives communicate over a system's internal bus, includes the ATA security command set. Among these is a command that when passed to the drive sets it into a 'locked' state, making it inaccessible until the correct password is supplied to unlock it.
ATA locking is the equivalent to a physical disk lock in the sense that, if you remove a locked drive from a system and plug it into another one, it remains locked and unusable. Indeed, the drive won't even register with the host's controller if the correct password isn't supplied, thereby preventing data access by booting an alternative operating system.
If you've seen a computer, particularly a laptop or other mobile device, that allows you to set a 'hard drive password' in the BIOS, this will be ATA security. When a system starts and the BIOS queries the local storage devices it will prompt you for the password and pass this onto the drive. If the password is correct, the drive is unlocked and registers itself with the host controller.
Somewhat confusingly, SEDs can accept and honour the ATA security flag like any other drive, and retain the integrity of its encrypted data on the drive, but this is different from the pre-boot sequence of an SED which also prevents the drive booting until the correct key is supplied. However it is, technically, another level of protection.
While Linux has less support for authentication and encryption suites that support SEDs, it does come in handy for rescuing drives locked with the ATA command. If the drive is plugged into a system that doesn't support setting a hard drive password in the BIOS, it's not possible to unlock it before boot, even if you know the password. However, booting a Linux disk you can unlock the device using the 'hdparm' command. The drive can then be secure-erased, too, from Linux to provision it for use in another device if so desired.
Speaking of which, at least with respect to Microsoft's eDrive standard, note that not all ATA security commands will be honoured -- security erase, the method you would usually use to reset a drive to factory default, will be ignored by a drive operating as an eDrive. The only way to reset an eDrive back to factory state (security inactive and MEK regenerated) is to use a PSID reverting tool, and requires the PSID of the drive (which can be found printed on the drive itself). All the major vendors supply a PSID reverting tool for this purpose, though you may need to contact support to get it.
SEDs, good for business?
There are other advantages to using SEDs in the desktops and laptops on your network. Beyond the security of data at rest, there are also other advantages that include:
Performance -- self-encrypting drives are typically a little slower than their non-encrypted counterparts, but the difference is small enough to be negligible, and that's a good thing for-endusers (and when it comes to building a case for their deployment).
Transparency -- SEDs operate regardless of the hardware or operating system, and a unified unlock and single sign-on means the user won't even know it's there (and more importantly, can't disable it deliberately or inadvertently as with software running on the OS).
Key management -- as the encryption key is stored within the drive, there's no need to manage storing and backing up of encryption keys.
Sanitisation -- wiping an SED takes just a few seconds as a new MEK is generated. This makes deleting data for security or re-purposing a drive extremely cost-effective compared to the many hours it takes to securely wipe a drive through traditional disk-wiping software.
Compliance -- depending on your business, laws for compliance may include strict measures for data at rest, and here SEDs can help fulfil compliance regulations. That said, they're not foolproof. Some of the cons include:
Compatibility -- as previously mentioned not all management tools will work with all drives, and with Opal 2.0 being incompatible with Opal 1.0, it's essential to research the standards your chosen SED model supports matches the requirements offered by whatever endpoint or management suite you want to use.
Reliance on the drive -- whereas a software solution you can switch out or upgrade easily if an issue is found, the same is not true for an SED. Bugs happen with hardware, too, as the recall in 2012 of LSI Sandforce-based drives -- which included Intel drives -- revealed when the drive's controller was unable to operate with AES 256-bit as claimed.
Not bullet-proof -- It's easy to think of SEDs as inscrutable given the hardware-based encryption where the key doesn't leave the drive, but workarounds have been demonstrated with machines in sleep mode or booting alternatives OSes whilst the drive is in an 'unlocked' state, bypassing the initial security of the password to required to decrypt its data.
Still, SEDs are clearly a natural evolution of securing data in its journey from storage to system and back -- especially for mobile devices in the employee workforce -- and with the right implementation can add another layer of security and keep your business critical data where it belongs: inside the walls of your network.
This article is brought to you by Enex TestLab, content directors for CSO Australia.