User Manual

Enterprise Self-Encrypting Drive User’s Guide, Rev. B 19
There are two important points that should be emphasized from the foregoing discussion. The first is that the drive
protects the integrity of the user’s passwords by storing only their hashed values. This is true for SID and EraseMaster
as well as the set of BandMaster passwords. Since a hash is a one-way function, there is no way to recover the clear
text password from the stored hash.
The second point is that the data encryption key (DEK) is itself encrypted with the BandMasterX password before
being stored on the media. This is significant because losing the password for a data band means that the stored DEK
cannot be decrypted and that is tantamount to a cryptographic erase. In other words, there are two ways to perform a
cryptographic erase on a data band
1. Tell the drive to change the encryption key
2. Destroy the BandMasterX password
1
Before we move on, there is a particular scenario involving the DEK that is worthy of our attention. Suppose the drive
owner decides that the drive should not lock the data bands after a power cycle. This could be achieved by setting the
parameter LockOnReset = [ ]
2
rather than the customary LockOnReset = [Powercycle]. Now, if the drive is moved from
one system to another its data would be accessible as soon as power is reapplied. Since this leaves the drive wide
open to unauthorized access, it’s hardly a recommended procedure, but more than that, it causes a problem with the
encryption key. Why? Well let’s take a closer look.
Normally, after power up, the host will send the band password to the drive to unlock the band and allow the drive to
recover the DEK, as we saw in Figure 13. But if the data band is already unlocked when the drive is powered up, the
host doesn’t need to send the password and since the drive can’t derive the password from the stored hash, how do
we decrypt the DEK? Fortunately the drive knows that it will be faced with this dilemma as soon as LockOnReset is set
to null. The drive could simply get the DEK from the encryption engine and store it on the media as plain text. This
would solve the problem but it breaks the rule that says we are not allowed to store unencrypted keys on the media.
“Why not?”, you say, “the band is unlocked and we can read the data, so why bother about an unencrypted key?”
Good point. Well, because an unscrupulous but resourceful hacker might find a way to read the DEK and use it to
compromise your data should you decide to lock the band at a future date. Since storing an unencrypted DEK is not
the solution, the drive will use an alternate technique to disguise the key prior to storing it on the media.
To relock the data band, the host must first authenticate
3
to BandMasterX and the DEK encryption process reverts to
normal.
1 In this case, since the password is lost, the owner would recover the storage space by using the EraseMaster credential to change the encryption
key - as in a normal crypto erase. This has the side effect of unlocking the band and defaulting the BandMasterX credential to the MSID value
which in turn allows the owner to reinstate a new value for BandMasterX.
2 This represents a “null” value.
3 The host needs to prove ownership of the band by providing the correct value for the BandMasterX password.