Wave Systems Corp. (fka WAVXQ)

[Fullmoon]

Enabling drive-level encryption is only the beginning

http://blogs.techrepublic.com.com/security/?p=792


Date: February 11th, 2009
Author: Tom Olzak


The TCG released a new standard for encryption at drive-level. Sounds good, but how does this actually impact enterprise data encryption efforts, particularly pre-boot authentication?

——————————————————————————————————————-

Last week, the Trusted Computing Group (TCG) made an announcement which caused a burst of articles about disk encryption. The TCG released a new standard for encryption at drive-level. Sounds good, but how does this actually impact enterprise data encryption efforts, particularly pre-boot authentication (PBA)?

Encryption at the hardware/firmware level is not a new concept. Seagate, for example, announced a product called DriveTrust in 2006 which uses proprietary technology to encrypt its drives. DriveTrust uses AES or other standard encryption algorithms. So what why the hubbub about the TCG standard?

The TCG standard
The members of the TCG Storage Work Group decided that not having a standard drive-level encryption method was a bad idea. So, they created a set of security standards covering a wide range of storage technologies, including ATA, Serial ATA, SCSI, FibreChannel, USB Storage, IEEE 1394, Network Attached Storage (TCP/IP), and iSCSI. And the standard is not limited to magnetic storage. According to the TCG, storage systems include disk drives, removable media drives, flash storage, and multiple storage device systems.

The security standards set augments the TCG Storage Architecture Core Specification and includes three subsystem classes: end-user device (Opal), enterprise, and interface interactions. According to a January 27, 2009 TCG press release,

The Opal specification outlines minimum requirements for storage devices used in the PC client and enterprise markets. It outlines for vendors required and optional TCG capabilities and it specifies how to activate and customize the trusted storage device. Some vendors are starting to ship products based on the OPAL specification and have demonstrated how these are interoperable with those from other vendors.

The Enterprise Security Subsystem Class Specification extends the concepts of trusted storage devices to those used in data centers and high-volume applications, where typically there is a minimum security configuration at installation, a requirement to bring devices on-line quickly and the need for high performance with low overhead. The specification defines encryption of data on media and enables support for strong access control to support organizational security.

Finally, the Storage Interface Interactions Specification specifies how the TCG’s existing Storage Core Specification and the other specifications interact with other specifications and standards for storage interfaces and transports. For example, the specification supports a number of transports, including ATA parallel and serial, SCSI SAS, Fibre Channel and ATAPI. It was developed with input from representatives of those organizations. Importantly, it enables interoperability of trusted drives in legacy environments.

Documentation for each of these standards, including FAQs, is available for download at the TCG Web site.

This all sounds good. Standardized drive-level encryption. Administrators can encrypt end-user devices are placed into users’ hands. Future drives using the standard will enable data center engineers to implement server and disk array encryption on the devices themselves regardless of the hardware manufacturer. In both cases, end-user devices and data center systems, performance overhead due to encryption will be minimized. Finally, no centralized encryption management system is necessary… well, not so fast.

The specification does not include centralized management of an encryption solution. This will fall to encryption vendors to develop. However, the TCG provides interfaces to allow development of management software which will work across all types of drives. So this might not be a problem, assuming software development keeps pace with the release schedule of new drive technology.

Why centralized management is important
The biggest issue I face when managing an end-user device encryption environment is lost passwords. Passwords are lost when users have a lapse of memory or when disgruntled employees refuse to provide them as their being escorted to the exit. The standard does allow for multi-user access via different passwords. So an organization can deploy devices with both a user account and an account only for administrators. Sounds good on the surface, but there are issues when encryption passwords and keys are not managed from a central server.

If a user forgets his or her password, it can’t be reset without an admin having access to the device. To avoid this issue, organizations would have to maintain a secure disk password repository, assuming each user had different password. Not giving each user a different password means that every system has to be “touched” whenever an employee leaves the company.
If the administrator password is released to unauthorized personnel–we all know this never happens–every user or data center drive with that password is potentially vulnerable.
Regardless of whether PBA is controlled at the drive level or by software loaded into the master boot record, the protection provided is only as good as the authentication method used. In other words, weak passwords or password policies result in weak encryption. So in addition to using strong passwords, security policies (e.g., maximum login attempts) must also be enforced.

Organizations can implement other authentication methods to enable PBA. Biometrics is a good password replacement if multi-factor authentication isn’t necessary. Yet, fingers and sensors don’t always cooperate. There are times when entering a password is the only login option—unless your company accepts user’s taking a day off on the business.

The bottom line? Drive-level encryption is conceptually a great idea, but it is only one component of a successful enterprise encryption strategy. Without supporting management technology, encryption can cause more problems than it solves. And just because it is available and easy to turn on doesn’t mean you should enable it. Wisely choose when and what to encrypt. Make sure you understand and have planned for all the challenges faced when rolling out encryption. Otherwise, you might have a second chance to get it right at a new place of employment.