TCG-compliant SEDs
The specification in a nutshell
The core specification
The backbone of TCG's specifications for self-ecnrypting drives is the core specification. This specification describes how the firmware's configuration is organized and stored, and it also described how to communicate with the firmware to update the configuration.
Security subsystem classes
The core specification alone is not practical or suitable for storage device manufacturers to implement -- it's too broad and it's missing vital elements. To solve this problem, TCG issued several specifications that complement the core specification by selecting which features are mandatory and by adding some vital extra features. These complementary specifications are called security subsystem classes (SSCs), and there are currently six of them.
The six current SSCs:
- Opal 1.0 & Opal 2.0
- Opalite
- Pyrite 1.0 & Pyrite 2.0
- Ruby
- Enterprise
- Key Per I/O
While TCG Opal is the most common, SEDManager recognizes all of them and can fully configure most of them.
Core concepts in TCG SEDs
Due to the shared core specification, all SSCs follow a similar pattern. While it's not strictly necessary to understand these details in order to encrypt your drive, knowing a bit more can reduce the risk of messing up the drive or your data. Reading this will also clear up the confusion about all the different passwords you will be using during the encryption process.
Security providers
SSCs group their functionality into so-called security providers (SPs). (After writing a complete application and reading the term about a thousand times, I still don't really see why this became the name, but let's just roll with it.) While the specification is really flexible, current SSCs split their functionality into to security providers:
- Admin SP: The Admin SP exposes functionality related to the general management of the drive. This includes enabling and disabling the Locking SP and reverting the encryption configuration or the whole device into its factory defaults.
- Locking & KPIO SPs: The Locking and the KPIO SPs expose functionality for configuring how the drive is encrypted. They also provide means to access the encrypted data. The KPIO SP is specific to Key Per I/O devices, and works differently compared to the Locking SP present in the rest of the SSCs.
Authorities
Authorities represent individuals (users and administrators) who have the authority to perform some actions on the device. TCG-compliant drives employ a fine grained access control, so you can specify what actions an authority is allowed to do. Authorities exist within the context of a security provider.
The most important authorities on Opal, Opalite, Pyrite and Ruby drives:
| Authority | Security provider | Purpose |
|---|---|---|
| SID (Owner) | Admin SP | Enable or disable the Locking SP, revert the device |
| PSID (Physical owner) | Admin SP | Revert the device with a password printed on the device's label |
| Admin1..AdminN | Admin SP | Not used by SEDManager |
| User1..UserN | Locking SP | Unlock the device and access data |
| Admin1..AdminN | Locking SP | Set up and modify locking configuration |
Don't confuse the Admin SP Admins and the Locking SP Admins. SEDManager refers to the Locking SP Admins as AdminX.
Authorities on Enterprise drives (the Admin SP authorities are the same as above):
| Authority | Security provider | Purpose |
|---|---|---|
| EraseMaster | Locking SP | Erase locking ranges |
| BandMaster0..BandMasterN | Locking SP | Set up locking ranges |
Authorities on Key Per I/O drives (the Admin SP authorities are the same as above):
| Authority | Security provider | Purpose |
|---|---|---|
| Admin1..AdminN | Locking SP | Set up and modify locking configuration |
Passwords
SEDManager will often mention the owner's password, the physical owner's password, and the Admin1 password. These refer to the passwords of the respective authorities listed above, and you have to enter them before you are authorized to the actions described in the above tables. For example, you need to enter the physical owner's (PSID's) password before the device let's you revert it to its factory defaults.
Locking ranges
With the exception of Key Per I/O, the SSCs encryption capabilities are based on so-called locking ranges. Remember how devices store the data in a contiguous range of blocks? A locking range is just a subset of the entire range. Going back to the 1 TB example drive with 1.95 billion blocks, a locking range may be configured to represent blocks 0.5 billion to 0.7 billion, consisting of some 0.2 billion blocks. In addition to regular ranges, there is one global range, that includes all the 1.95 billion sectors of the example drive.
Each locking range has the following configurable parameters:
- Range start: The logical block address (LBA) of the first block of the locking range.
- Range length: How many logical blocks the range encompasses.
- Read lock enabled: If checked, the range will get read-locked after a power cycle.
- Write lock enabled: If checked, the range will get write-locked after a power cycle.
- Read locked: If the range is currently locked for reading.
- Write locked: If the range is currently locked for writing.
- Active key: The media encryption key currently used to encrypt the blocks of the range.
In Enterprise drives, the ranges are called bands, while Key per I/O doesn't have locking ranges.
How data is encrypted
Media encryption key
The key used to encrypt the blocks inside a locking range is called the media encryption key (MEK). The MEK is a randomly generated password that is being fed into a symmetric encryption algorithm, effectively encrypting all data that is written to that range's blocks. The MEK is also used to decrypt the data read from the range's blocks, making it readable to the operating system and your apps again.
Erasing a locking range
Since the only way to access data in the locking range is via the MEK, erasing a locking range is very easy: just delete the MEK. The data is still there, but there is nobody who can actually read it. This is called crypto shredding, and is different than older methods like repeatadly overwriting the entire drive with random bytes. Instead of taking hours, it only takes a moment, and it's also extremely safe.
Key encryption key
If the MEK is a random password, and you don't even have access to it, then how do you actually unlock your drive? If changing the MEK erases the entire drive, then how can you change your password once you encrypted the drive? The answer is the so-called key encryption key (KEK). The name sounds strange, but the KEK is called like this, because it is used to encrypt the media encryption key.
With this two-level system, reading a block of data from the hard drive requires the following steps:
- Ask the user for their password. (The password is the key encryption key.)
- Use the user's password to decrypt the media encryption key.
- Read a block of data from the disk.
- Use the media encryption key to decrypt the block of data.
- Present the decrypted block of data to the user.
- Forget the decrypted MEK, but keep the encrypted MEK in memory.
- Forget the user's password (i.e. the KEK).
This way, we have gotten a block of data out of the locking range, we've successfully decrypted it, and after forgetting the keys, nobody can access more data.
Notice that this system is very flexible. There can be multiple users, each having their own password (KEK). The device can store a copy of the MEK encrypted with each of the different KEKs, meaning multiple passwords can unlock the same locking range. You can also easily change the password (KEK) of a user, because it does not actually need changing the MEK (which would erase the locking range). You just have to reencrypt the MEK with a different KEK.
Booting from encrypted drives
Encrypting every single block on the disk sounds enticing, but there is a little problem with it: if the partition table and the operating system's bootloader is encrypted, then how are you going to boot the computer? The solution to this in TCG-compliant drives is called MBR shadowing. When the device is encrypted and locked down, it can be configured to appear as a small (128 MiB) read-only drive, called the shadow MBR. During configuration, you can upload a small program on the shadow MBR that asks you for the password when booting and then unlocks the encryption on the drive. This causes the drive to switch to showing the unlocked contents of the drive, revealing the actual partition table and the operating system's bootloader. At this point, the operating system can boot as normal.
Configuring devices
Luckily, you don't have to deal with KEKs and MEKs when configuring the device -- these details are hidden even from SEDManager. Configuration roughly comes down to:
- Setting passwords for certain authorities (mainly the SID, and Locking SP Admins and Users)
- Configuring the location and locking status of locking ranges
- Giving users permission to lock and unlock certain locking ranges
Read more about doing that in the usage section.