On June 11, 2013 the Trusted Computing Group (TCG) alongside its key panelists, Tom Coughlin of Coughlin Associates, Michael Willett, Samsung and Hussein Syed of Barnabas Health hosted a webcast on the realities of using self-encrypting drives today, now that they are becoming widely available for client and enterprise. The presentiation materials are also available for download.
The following questions were posed during the webcast. TCG’s panelists and storage security experts have answered them for you. For any others, please contact [email protected].
Can you talk more about the customer service experience and capabilities that were enabled by using this technology?
A: Use of SED based drives has the big benefit: there is no performance trade off on the device. The only areas where we (Barnabas) have developed support processes are around password recovery and re-provisioning of devices.
In healthcare, if you lose or have lost a device, how did SED technology help you with reporting, costs and securing data?
A: In healthcare, if a device is lost, a risk assessment is required to determine if there is patient information at risk. SED, if implemented properly, offers a ‘safe harbor’. If the password used to lock the drive is strong and a provider can demonstrate it, SEDs can help an organization not go through an expensive breach notification and reporting exercise.
If these technologies start to become more consumer oriented and in several types of different devices, would this satisfy any compliance or regulatory successes for healthcare providers?
A: The BYOD initiatives will gain momentum if SED can be used to protect data, as long as an organization can manage the SED and demonstrate setup is secure.
What is the average TCO differential between SEDs and the best software encryption?
A: This can be referenced in the new Ponemon study on TCO of SED/FDE available here.
Regarding Hardware Acquisition, when is price parity expected between a normal hard drive and a self-encrypting drive?
A: Several providers of SEDs have already gone to no-markup. And, any current markups are in the ‘few dollars’ range; all moving to the point in the future when ALL drives will be SEDs.
What is your long range view of using SEDs in the enterprise?
A: SEDs in the data center will make it easier to retire, replace and repurpose storage devices while preserving security for sensitive data. In addition, security management is easier for SEDs than for software encryption. Thus SEDs in the enterprise will provide advantages, driving universal adoption.
What are the future forecast and adoption curves for SEDs for consumers?
A: Non-mobile consumer devices such as DVRs and game consoles don’t gain much benefit to the consumers and thus this is a market that will generally adopt SEDs as these drives become universally uquiquitous.
You mentioned the details of doing a “NIST-approved crypto-erase”. Do you know if the NIST is going to be working the “crypto-erase” into any of their FIPS documentation under the destruction of media?
A: Revision 1 of NIST SP800-88 – “Guidelines for Media Sanitization” contains CryptoErase, based on SEDs. After the draft is accepted in final form and CryptoErase is a formal NIST-sanctioned sanitization method, we can expect other government documents related to sanitization to officially recognize CryptoErase. A draft of this document can be found here.
How do we escrow the key to allow for forensics on a SED in the enterprise?
A: You cannot escrow the ENCRYPTION key(s) for an SED, since those keys are never externalized. You can escrow the AUTHENTICATION key(s), as do all the software products that manage SEDs. If you do not have the authentication key for an SED, then you cannot perform ‘forensics’ on the drive; that is, read the on-board encrypted data. The encryption is doing the job it was designed to do: keep the ‘unauthorized’ person from reading the encrypted data. Of course, assuming the data is important to the owner, that data is backed up in the enterprise; available otherwise to the authorized person.
How do I handle forensics on an SED?
A: Refer to the answer above for more information. The only information available on the SED media are: encrypted data, hashed authentication key(s), and only an encrypted copy of the encryption key. Given the strength of the underlying standard cryptography, “Crypto 101” says that the data cannot be recovered from those elements. In that sense, you cannot do “forensics” on an SED. Reputable recovery companies have already found this to be true.
How to use SED in an unattended environment such as servers? If the server is rebooted, in some cases, it is not acceptable that an admin has to enter a password so the server can be back online again.
A: The pre-boot authentication scenario presented in the webinar applies to the OPAL/laptop, not the enterprise and data center environment. Two similar but different TCG trusted storage specifications apply. The enterprise specification assumes an unattended/automated environment such as a data center server and/or RAID system. In this case, the RAID controller (and/or key manager) is programmed to present the authentication credentials in an automated fashion. Products that have already announced support for enterprise SEDs take this approach.
Is TCG doing any work to get this level standardization of encryption and manageability on a thumb drive?
A: If the thumb drive supports on board AES-based hardware encryption and has the ability to securely store and execute microcode, then the TCG trusted storage specifications can be considered by the product vendor. Most thumb drives support a USB interface, which is based on the SCSI command set. The standardized “container” commands that carry the SED management commands are both T13 (SATA) and T10 (SCSI) based, as well as any derivatives of those command sets. The advantage of adhering to the TCG specifications for any encrypting storage device is the common manageability afforded such products. We encourage such product vendors to consider the TCG specifications in their designs.
Is there intention to expand TCG storage standards to mobile phone’s memory, or to usb flash drives?
A: Refer to the previous question for more information. The Mobile Phone Workgroup has published specifications for a trusted phone, including a hardware module called the Mobile Trusted Module (MTM). Prototypes have already been implemented to those specifications.
Will OPAL be implemented in other device types?
A: As noted earlier, the prerequisites for a storage device to implement OPAL (or the enterprise specification) for SEDs are:
The rest is programming. Besides the encryption, the SED advantage is the common manageability.
Is the Authentication Key equal to the user’s password? If so, isn’t there a risk of it being too short? And therefore, exposed to dictionary attack on the hash value? Moreover, how is the authentication password turned into an AES 128/256 key?
A: The Authentication key(s) are managed by the user/owner and can be up to 32 bytes long (256 bits!). As you have noted, due diligence dictates that long AKs be used. The AKs are used to authorize unlocking the drive and internally decrypting the encryption key(s). In that sense, the AK is one of the user’s passwords, but albeit a long password. Passphrases, Active Directory, external dongles, or other automated functions can be used to create long AKs that are still manageable.
The AK is NOT used to generate the Encryption keys. The EK are generated randomly on-board the drive and never externalized.
What do you recommend for AK management in systems that don’t have an interactive user or that need to reboot automatically?
A: For OPAL/laptop drives, you can integrate AK management with Active Directory (as supported by multiple management vendors) or some other resident function. The management vendors have their own automation capabilities. The TCG specification does not specify these behaviors. That is left to the management vendors in differentiating their products. To the SED management interface, the authentication key is a 32-byte “blob”.
How do we change the AK key without the loss of data on the SED? Is not a single AK used to encrypt the SED and changing this key destroys the data or makes it unreadable?
A: Refer to the above questions for more information. The Authentication key(s) and the Encryption key(s) are distinct.
The EK is generated internal to the drive and never externalized; not derived from the AK.
How difficult is it to convert existing servers to use SED drives?
A: You are encouraged to contact enterprise SED vendors and integrators and review their deployment strategies. Such conversions are beyond the scope of the TCG (a standards group). But, we have observed with satisfaction that such vendors are making the transition ‘graceful’. For example, SEDs can possibly be added to a RAID system in ‘unmanaged/unlocked’ mode until the time when the SEDs become ‘managed’; all in automated fashion. “Managed” means locked/unlocked using Authentication key(s). The server and/or RAID controllers (and key management systems) need to support such management; ie, administering the authentication key(s) and presenting the AK to the SED. Since SED management is carried over a standardized set of ‘container’ commands (either SATA or SCSI and derivatives), modifications to servers and RAID controllers can be minimal to none.
What happens with SEDs when the drive fails and requires recovery? Backups are not always implemented even though they should be. Is there a way to recover lost data from SEDs?
A: See the discussion of forensics above. Briefly, the answer is NO. The whole design point was to prevent the ‘unauthorized’ person from having the data on the SED. Backup of valuable data is necessary. The strength in design of an SED cannot be compromised simply because an I.T. person (or myself) failed to adhere to one of the fundamental best practices in I.T.: Backup.
What is meant by DATA CLASSIFICATION in this context?
A: Some customers have been forced to ‘classify’ data into sensitivity categories (eg, public, sensitive, confidential, personal, etc) in order to decide which data sets get which level of security protection, such as encryption, because the encryption function (eg, crypto co-processor) does not have the capacity to encrypt all data. With SEDs, every drive has a full-drive-speed encrypting engine, so that ALL stored data in the enterprise can be encrypted. Of course, you may classify data for purposes other than preserving a limited encryption resource.
If I have a SED installed on my desktop and am viewing this TCG presentation, is ALL of my data unreadable to a hacker, who is also on this channel?
A: If you are the authorized user of that desktop and you have unlocked the drive with the correct Authentication key during the pre-boot authentication process, then your drive is operating as a normal (open) drive. Everything written to the drive is always being encrypted transparently, but any function on your desktop that can read/write an open drive can also read/write your drive. Once you shut down the desktop, the drive goes into locked mode and will not unlock without the proper authentication key. Keep in mind: the encryption only applies to data written on the drive media, not to reads outside the drive. All reads come out as plain text.
So, for your scenario, ask the same question for any open drive (not just an SED). Can a hacker read data on your desktop from a webinar channel? I doubt it. What would be the ‘communication’ channel?
Membership in the Trusted Computing Group is your key to participating with fellow industry stakeholders in the quest to develop and promote trusted computing technologies.
Standards-based Trusted Computing technologies developed by TCG members now are deployed in enterprise systems, storage systems, networks, embedded systems, and mobile devices and can help secure cloud computing and virtualized systems.
Trusted Computing Group announced that its TPM 2.0 (Trusted Platform Module) Library Specification was approved as a formal international standard under ISO/IEC (the International Organization for Standardization and the International Electrotechnical Commission). TCG has 90+ specifications and guidance documents to help build a trusted computing environment.