In November at Blackhat Europe 2015, two forensics experts from KPMG Canada presented their findings in a presentation titled “Bypassing Self-Encrypting Drives (SED) in Enterprise Environments”.
To summarize they outlined 4 “attacks” on computers with SEDs:
- The Hot Plug Attack where they install a SATA data and power extension cable while the machine is in Sleep mode.
- The Forced Restart Attack where they trigger a soft-reset and boot from an alternative OS on a USB memory stick.
- The Hot Unplug Attack where they attack exposed SATA data and power pins.
- The Key Capture Attack where in Sleep Mode (S3) they replace the SED with a tampered drive with custom firmware or sniff the SATA bus to get the password.
Some of the attacks are easier than others. The easiest, the “Hot Plug Attack” requires that the computer be configured to automatically resume (unlock) from Sleep (Power State S3). From there they get harder employing some specialized equipment or requiring some physical dexterity. In any case a determined adversary should be able to achieve success with any of the attacks. However, the most important thing to note about all four attacks is the precondition that the SED is unlocked at the time of the attack!
SEDs are not designed to protect against data access after the storage device has been unlocked using a valid authentication credential. A SED (including a TCG Opal SED) is designed to prevent data loss due to a lost or stolen storage device, or the loss or theft of a system into which an SED has been integrated. This protection against data loss requires that the user has been de-authenticated from the system, for example, by a power cycle.
In fact SEDs share this characteristic with software full disk encryption (FDE). That is, both software FDE and SEDs provide cryptographic protection for data at rest only BEFORE the user authenticates at pre-boot. After the data encryption key (or media encryption key) has been made available to the cryptographic engine to transparently encrypt and decrypt the data, the level of protection of the data is solely reliant on the operating environment and this protection is orders of magnitude weaker than a properly implemented encryption scheme.
I have written before on why PBA (Pre-boot Authentication) is important for FDE. Encryption of any form doesn’t provide confidentially without authentication. For example, a computer with a SED or software FDE that boots right into a user’s account without prompting for a password or some other form of authentication leaves the data completely exposed.
The need for authentication is obvious and the two basic choices are:
- Authenticate the user before the drive is unlocked and the OS is booted up.
- Authenticate the user after the drive is unlocked. Unlock the drive automatically, then load the OS or an application and prompt the user to authenticate.
The KPMG – Blackhat presentation lists one common mitigation for all the attacks: “Users: Power-off or Hibernate laptop when unattended”. This will force authentication at pre-boot, i.e. option 1 from above, and provide the true cryptographic protection for data at rest that one would expect of FDE.
That said, based on a risk assessment and the particular usability requirements of an application, there may be other mitigations that reduce the risk of loss of data to an acceptable level allowing the use of sleep and not requiring the user to hibernate every time they leave their machine unattended. The report suggests laptop manufacturers could detect drive unplug in Sleep Mode and Hard-reset on tamper or the SED manufacturers could detect SATA data disconnect and lock the SED on tamper.
WinMagic has a keen interest in self-encrypting drives and has been working on solutions to automatically put the drive in a secure mode when conditions warrant. For example, our most recent product release supports Intel® Enterprise Digital Fence where hibernation is forced when the machine goes outside the bounds of the enterprise. WinMagic also has a proposal in front of the TCG for a mechanism where the SED itself could detect that it is no longer communicating to the original trusted “Host” that unlocked it at PBA and put it into a cryptographically secure state.
