SELF-ENCRYPTING DRIVE (SED)
US CYBER VAULT USES ONLY SED FOR SECURE DATA STORAGE TO GUARANTEE
ALL DATA AT REST IS compliant, and PROTECTED FROM ATTACKERS AND HUMAN ERROR
commonly asked questions and answers on self-encrypting drives
Why is hardware-based encryption more secure than software encryption?
A: Software can be corrupted or negated; hardware cannot. Software runs under an operating system that is vulnerable to viruses and other attacks. An operating system, by definition, provides open access to applications and thus exposes these access points to improper use. Hardware-based security can more effectively restrict access from the outside, especially to unauthorized use. Additionally, dedicated hardware can have superior performance compared to software.
Doesn’t hardware encryption negatively impact the performance of systems?
A: Not at all. Dedicated hardware (electronic circuitry) can always out-perform software (computer programs) running on a general-purpose OS-based platform.
What is special about SED? Does it have an internal engine in it?
A: The self-encryption function has several special capabilities, among them: 1. High- performance, dedicated electronic circuitry for the cryptographic engine embedded in the drive electronics and operating at full channel speeds, 2. encryption that is transparent to the user, the OS, and applications 3. ease of maintenance.
How is the key on the drive protected?
A: The original encryption key value is generated in the factory by an on-board random number process; it never leaves the drive. When the drive is configured by the user (or I.T.), the authorization key is used to encrypt the encryption key inside the drive, so the key is never stored in the clear. The encryption key can be changed by the user administration function (IT department), which ensures that anybody who might have had possession of the drive before the user puts it into service could not have obtained any information that might give him any help in later retrieving data from the drive.
What happens to data in flight?
A: Different and proven techniques (eg, SSL/TLS) are used to protect data in flight. Self-encrypting drives are focused on data at rest.
How do you define extensive data read? Why doesn’t startup throughput vary?
A: “Extensive data read” means that a large file is being read continually, instead of inter-mixed read/writes. The start-up TIME does vary; tests have proven it much faster for a drive running hardware self encryption than software encryption.
The performance data shows the SED as faster than a non encrypting drive, is that correct?
A: That does sound counter-intuitive, since the SED function, even in hardware, suggests a longer execution path length. But, the encryption function takes so little time that it is less time than the drive model variation in performance. So, it is possible for a particular SED drive to be faster than a particular non-SED unit of the same model.
How is the access to the drive secured to allow only the Authorized user to access it? Is there a boot- up password that is entered via a BIOS dialog?
A: When the BIOS requests the Master Boot Record from the drive, the drive instead returns the pre-boot record to the user. This pre-boot record is a complete, though quite restricted OS, usually something simple like MS-DOS or LINUX. The pre-boot image requests the Authentication Credentials from the user, which are passed to and checked directly by the drive logic. If accepted, then the drive returns the MBR and the OS is loaded. Important point: This pre-boot authentication is the FIRST thing that happens and is controlled by the drive directly. This has the added advantages of not modifying the MBR, which many software encryption products do, and allowing the MBR to be encrypted like all other user accessible data.
The encryption key is generated during manufacturing, presumably at an Asian subcontractor. Why should I trust a contractor with a key that lasts the lifetime of the SED?
A: The encryption key is generated on board the drive and NEVER LEAVES THE DRIVE. The manufacturer does NOT retain or even have access to the key. Moreover, you do not have to trust it. When putting an SED into service it is considered good practice to start by directing the SED to regenerate its encryption key. Doing this before loading any software on the drive eliminates the possibility of the drive manufacturer ,or anyone else who might have had a chance to access the drive before the current owner, acquiring any secret, like the encryption key, that could be later used to break into the user data.
How does SED help in protecting data that resides with a database or its tables?
A: ALL data on the drive is encrypted, including any data stored at a higher logical level, like a database or tables.
Have SEDs been legally approved for use in restricted countries e.g. Libya, Pakistan, India and Iran, where I believe there is local legislation which outlaws encryption?
A: SEDs have gotten EXPORT licenses from the U.S. Dept/Commerce/BIS. You are asking about IMPORT restrictions, which vary greatly by country. Several web sites track the status of cryptography export worldwide:
Keep in mind that an SED is not a general purpose encryption tool. The cipher-text is not available to the user; rather, it exists on the drive media. The U.S. federal government does restrict shipments to five specific countries considered dangerous.
What happens to the data if it the key gets stored on or the space it is stored on goes bad? Is there any recover ability?
A: An SED is used to protect the data stored on that one drive. Good security practice dictates that important data is backed up somewhere else for recovery. To combat an occasional bad sector, some SED drive vendors write the encrypted encrypting key to several storage locations, thus greatly minimizing the chance that all encrypted copies are lost.
The TCG OPAL specification includes transaction semantics, which requires multiple copies of the credential values.
Of course, there is no substitute for good data management practice, which starts with a regular data backup process.
Is there anything in place to account for those anomalous situations that seem to crop up, such as a corrupted key?
A: Yes. First, back up any sensitive data. Self-encrypting drives only protect that one copy of data. Note that the SED does not hinder in any way the use of storage management utilities, such as backup and recovery.
So, if the sector containing the DEK is corrupted, you basically lose your data?
A: No. Sensitive data should always be backed up on other storage; an SED only protects that one copy. And, the encrypted DEK is typically written to multiple locations on the drive to minimize the vulnerability to a single corruption.
How is data recovery from a crashed SED handled?
A: If the encrypted data, the encrypted Data Encryption Key, and the Authentication Key are not available, then the data is NOT recoverable from that one drive. However, good security practice encourages valuable data to be backed up. Simply retrieve the back-up copy.
Is drive sanitization now a thing of the past?
A: No, it is still needed. Drive sanitization is now much easier; just change the DEK and all data is erased!
How does the self-encrypting drive concept work for secure cloud storage?
A: For the client machine that might cache data on the local machine, all data stored on the local self-encrypting drive will be encrypted and not accessible unless the Drive is unlocked. For the cloud machine that stores the data, a self-encrypting drive can be utilized to store all data for future sanitization purposes. The data transfers between the client machine and the cloud machine will likely use some existing protocol (VPN, SSL); the data that is sent to the drive will be in clear-text across the SATA or SAS interface. The data encryption for self-encrypting drives encrypts and decrypts the data in the drive (for data at rest, either at the client or in the cloud) and does not facilitate encryption for data in flight.
What is the time difference between sanitizing an encrypted vs non-encrypted drive?
A: The time difference depends on the size of the drive. It takes less than a second to erase/overwrite the DEK in an SED, irrespective of the capacity. It can take hours-to-days to overwrite a two-terabyte non-SED disk drive .
I did not understand how the encryption keeps information safe if the key is on the drive as well. What prevents the drive from being moved to a new secure storage disk array?
A: First, there is no clear text copy of any key on the drive. Second, the SED can be moved to a new secure storage disk array. However, once the SED is powered on, the drive will ask for the same credentials (the AK) to unlock the drive (decrypt the DEK) as were required on the old system. If the correct AK is not given, the DEK cannot be decrypted. Only the hash of the AK and the encrypted form of the DEK are ever stored on the drive.
Since the drives are always encrypting on SED, just changing the symmetric key in firmware would erase the drive, right?
A: Yes; exactly, and this is an important advantage. To erase the drive, you simply need to change the DEK that the drive is using and overwrite/erase the previous encrypted DEK that is stored on the drive. This entire process is accomplished by issuing a single TCG command that is usually exposed by the management software as an erase button the user simply needs to select. The software usually follows that with one or more questions, asking the user if he/she is certain that the drive should be erased.
When creating the hash, does that get stored on the drive media itself or on the dedicated IC chip? Is the hash stored in an encrypted state? How does it get read or pass the challenge-response if it is encrypted?
A: Where the hash is stored is product dependent and not specified by the TCG standard. The hash can be stored on the drive media in an area not accessible by users. The drive’s firmware knows how to read the Hash for comparison to the hash of the submitted AK. This is the standard way that passwords are protected: store only the hash and compare hashes for authentication.