Self-encrypting drives in TCG Opal / eDrive mode

Impact

Three related bypasses that all exploit the same design assumption: an SED stays UNLOCKED once the platform has authenticated it, and only re-locks on a true power cycle. If the drive never sees power drop - hot-plugging a SATA drive while the machine sleeps, forcing a soft reset and booting an alternative OS, or attaching a second SATA connector and an alternate power source before pulling the data cable - the DEK stays live and the attacker reads plaintext with no credential. Included here because this is the CLASS of failure operators keep re-encountering: the newer Solidigm 'locked drive is not locked' CVEs are the same assumption failing again a decade later. BREAKS TENANT HANDOFF for any workflow that assumes a drive is safe because it is locked - locked-while-powered is not locked, and a running or sleeping node is a readable node.

Who can reach it

A physically proximate attacker with access to the running or sleeping machine and its drive cabling - a colo neighbour, a rack tech, or anyone who reaches a node between tenancies while it is still powered. No password required.

What to do

Mostly a policy and platform-configuration fix rather than a drive flash - the drives behaved as the Opal model specified, so there is no universal firmware patch. Concretely: disable sleep/suspend states on bare-metal hosts so the drive is never in the powered-but-unattended state that makes hot-plug work, require full power cycles rather than soft resets in your reclaim path, and verify that the platform re-authenticates the drive after any reset. Between tenants, do not hand over a node that has merely been rebooted - power it fully down as part of reclaim. The durable answer is the same as everywhere else in this category: software encryption with an operator-held key, so that a drive left unlocked still yields only ciphertext to whoever gets to it.

References