It is quite common these days to hear of sensitive information being lost when laptops are either stolen or lost. Rarely does a month go by without an organisation revealing the loss or theft of a laptop brimming with sensitive data. Full disk encryption, or FDE, is the preferred mechanism to address this threat.
As the name implies, the technology lets IT encrypt the entire hard drive so that sensitive data is protected, no matter where it resides. But unfortunately, FDE adoption comes at a price: complex and costly deployments, additional licensing fees, and one more application for IT to support.
The adoption of a new standard called OPAL aims to remedy some of the pain areas of software based FDE.
The need for FDE
All operating systems be it Mac Os, Linux or even Windows have some built-in support for file system level encryption. While file encryption is still better than encryption, it still leaves encryption at the hands of the user. There are still some fundamental questions that remain unanswered-
Did the employee put all sensitive data into that target folder? Was anything left in caches or temporary directories?And perhaps most critical, without FDE, if a device is stolen or lost, how do you definitively know that all of the sensitive information it contained was encrypted?
Software-based FDE products, the data on the drive can only be accessed when the operating system is booted and the encryption keys unlocked. But the technology isn’t perfect–software-based FDE also has drawbacks.
Software FDE products are OS dependant, most software don’t support Linux or Mac OS X. The encryption process is dependant on the processing power and therefore the encryption process could slow down a machine. Also encryption keys are stored in the computer’s memory, which makes them vulnerable to a class of cold-boot attacks, where keys can be recovered from the RAM
The OPAL standard
In January 2009, the Trusted Computing Group released the final specification of the Opal Security Subsystem Class, a standard for applying hardware-based encryption. Hardware based encryption has the following advantages:
- It is not OS dependant
- The encryption process is moved to dedicated processors, thereby reducing the load on the system’s CPU
- The encryption/decryption keys are stored in the hard-drive controller and never sit in the system’s memory, making “cold boot” attacks ineffective.
- Hardware-based FDE also simplifies the key escrow dilemma–that is, the need to manage encryption keys. The keys used by the hard drive can be unlocked only by a passphrase entered during the pre-boot sequence. The passphrase is sent to the hard drive controller before the OS boots, so the keys never leave the hard drive’s hardware. Also, multiple passphrases can be configured to unlock those keys.
The only issue that could work against hardware based FDE is the inability to build custom encryption algorithms or have variable strength keys, which is currently possible with software-based FDE’s.
Pre-requisites to implementing a Hardware based FDE
Without an integrated management infrastructure, enterprise deployment and support of Opal-compliant hard drives will be a nightmare. There are a few key features that are essential.
Organizations must manage boot passwords and password resets. If an employee leaves, becomes unavailable, or just forgets the password, IT needs a way to access the data on the drive. Conversely, if an IT administrator leaves, the organization must be able to change admin accounts.
Organizations with global software FDE deployments are not likely to abandon their existing installations as it will take time for companies to swap in laptops with Opal-compatible drives.
In contrast, on the manufacturing side, vendor support for hardware-based FDEs is good. In the last six months, Fujitsu, Hitachi, and Samsung have debuted Opal-compliant drives, and system vendors Dell and Lenovo are shipping laptops with Opal-based drives.
So it appears that hardware based FDE’s have some inherent advantages that are too compelling to ignore and therefore could eventually be widely used.