For those unwilling to sacrifice performance for security, there are hardware-based strategies for faster encryption, says Jason Brooks
Disk encryption for client endpoint computers has long been recognised as an important safeguard against data exposure, particularly for notebook computers, which are easily lost or stolen. It’s trivial to bypass typical operating system protection measures by popping out a drive and accessing its data from a separate machine.
Still, most mobile clients are deployed without disk encryption, despite the broad range of disk-encryption solutions available. In a September 2010 report on disk encryption usage, security vendor Opswat found that just over 10 percent of the desktop and notebook endpoints they sampled were protected with disk encryption.
Among the roadblocks in the path of broader adoption of disk encryption is the performance hit associated with the technology. Full-volume encryption involves encrypting and decrypting all data written to and read from an encrypted disk, with an I/O performance penalty.
In the product information for Microsoft’s Bitlocker disk-encryption feature, the company characterises the overhead as a single-digit performance difference, but the hit will vary based on the system and its running operations.
In my own experience with mainstream notebooks and even with lower-powered netbook systems, the encryption overhead is noticeable but well worth it for the peace of mind it brings. However, for those loath to sacrifice performance for security, there are hardware-based strategies for accelerating encryption and reducing its overhead.
One such method, Intel’s AES-NI (Advanced Encryption Standard New Instructions), works to enhance performance by building specific AES encryption and decryption instructions into the CPU. According to Intel, AES-NI can, when teamed with software written to take advantage of it, enable performance increases in the order of 300 percent to 1,000 percent.
Microsoft’s Windows Bitlocker takes advantage of AES-NI support, as does the Linux kernel, among other applications and libraries. To get an idea of the sort of performance benefit possible with AES-NI support, I performed some tests in our lab with a Lenovo W520 notebook powered by an Intel i7-2920XM quad-core CPU.
I tested with a Linux distribution, the recently released Fedora 15, because I was able to compile a separate kernel with AES-NI support disabled. By default, AES-NI support is active in the Fedora 15 kernel. I installed and tested the system with no disk encryption, and with disk encryption enabled at install time. I tested the encrypted system with both AES-NI enabled and AES-NI disabled kernels.
I tested by recording, over repeated test runs, the time to took to copy a large, 4.3GB ISO (International Organization for Standardization) image from a USB 3.0 external hard drive to the desktop of my test system, the time it took to copy out the many smaller files within that image to a folder on the desktop, and the time it took to copy the image from the desktop to a separate location on the drive under the tmp directory.
In my tests with the large file, the overhead I recorded between the encrypted and non-encrypted versions of this system was significant, and the enhancement I experienced with AES-NI enabled was fairly modest. On the system without AES-NI enabled, the ISO image took 39 percent longer to copy over, compared with the unencrypted system. With AES-NI enabled, this overhead dropped to 32 percent.
In my second test, copying many smaller files from one location on the drive to another, the differences between encrypted and unencrypted were smaller, but still significant, at 9.6 percent without AES-NI enabled, and 9.5 percent with AES-NI.
AES-NI can deliver benefits beyond full-volume disk encryption; given software support, many different operations that involve AES encryption can see an enhancement with the instruction set. I ran a separate test with my pair of kernels to measure the effect of AES-NI on the OpenSSL library, which, in the version that ships with Fedora 15, supports the instruction set.
I measured the time it took to encrypt my trusty 4.3GB test image at the command line using OpenSSL, and recorded a performance bump of 25 percent with my AES-NI-enabled kernel, compared with the kernel with the instruction set disabled.
AES-NI is one of the elements included in Intel’s vPro 2 feature set, and organisations can expect to find the capability in a variety of mainstream notebook systems. Here’s a list of the Intel processors with AES-NI support.
I took a look at Dell’s enterprise notebook lineup and drilled down into the configuration tool for the first such system on offer, a Latitude E6520. All four of the processor options available for the system include AES-NI.
For its part, Advanced Micro Devices will ship processors with support for AES-NI beginning with its “Bulldozer”-based processors.
Self-encrypting drives offer another option for boosting the performance of disk encryption without the reliance on CPU, software or operating system support. These drives locate the hardware for carrying out encryption operations within the drive itself, and promise performance nearing that of unencrypted drives.
Seagate, Toshiba, Samsung and Hitachi all market self-encrypting drives that abide by common standards published by the Trusted Computing Group.
While self-encrypting drives have been around for some years, they have a somewhat lower profile in the market than do AES-NI-enabled processors. For instance, the Dell Latitude system I cited was available with a self-encrypting drive option, though this option required an upgrade to a larger, 320GB drive, and came with a $20 to $40 premium above the standard 320GB drive option.