SEDs use a password to generate KEK by a KDF algorithm. The KEK is then used to encrypt the MEK (where MEK is internally generated in the drive). But TCG-Opal drives have 9 locking-ranges and each of these ranges use its own MEK (say MEK1 – MEK9). There are also 4 Admins and 8 Users, each has its own password (PIN). Which of these passwords are used to generate the KEK, or are there multiple KEKs ? The TCG core spec and the Opal SSC spec don’t detail the relation of a password to the MEK of any locking-range.
I’m looking for a TCG-OPAL protocol stack agent, to be working on the SSD side. I found partial implementations of host-side TCG-OPAL. These are opening sessions and initiating the commands. I need the side that serves these commands, residing on the SSD. Host side TCG-OPAL implementations:
- Drive Trust Alliance: https://github.com/Drive-Trust-Alliance/sedutil
- Linux source code: https://elixir.bootlin.com/linux/latest/source/block/sed-opal.c