In a previous blog I wrote that at Black Hat Europe 2015, two forensics experts from KPMG Canada presented their findings in a presentation titled “Bypassing Self-Encrypting Drives (SED) in Enterprise Environments”.

To quickly summarize they outlined 4 “attacks” on computers with SEDs:

1. The Hot Plug Attack where they install a SATA data and power extension cable while the machine is in Sleep mode.
2. The Forced Restart Attack where they trigger a soft-reset and boot from an alternative OS on a USB memory stick.
3. The Hot Unplug Attack where they attack exposed SATA data and power pins.
4. 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.

So why does this problem exist?

SEDs are not designed to protect against data access after the storage device has been unlocked using a valid authentication credential. 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. This protection is orders of magnitude weaker than a properly implemented encryption scheme.

What is the solution to this problem?

To address these attacks, we identified the root cause of the whole class of problems and then derived a solution. What we saw, that others had missed, is that the SED has to become a stake holder in ensuring that the authentic user or authentic OS that was present shortly after the original trusted user   authenticated is still present.  i.e. It is not an attacker who has swapped in his own OS instance for purposes of data exfiltration. We do this by introducing the concept of a trusted session that persists even over power cycles of the SED when the computer sleeps! It is the crypto-heartbeat from the original authentic OS that the SED uses to monitor the authentic OS. If the crypto-heartbeat doesn’t arrive when it should or is tampered with then the SED takes action and locks itself (i.e. puts itself into a cryptographically secure state that requires full authentication to establish another trusted session and unlock the drive).

The solution is called, Crypto-Heartbeat as it uses a cryptographically encoded periodic message (the heartbeat) to keep a trusted session alive between the host and the SED.

Crypto-Heartbeat between the SED and the host system has the following properties:

• Shared secret (symmetric Heartbeat Key) between the host instance and SED estab­lished shortly after the original pre-boot authentication
• SED configured to require periodic heartbeats from host based on shared key
• SED retains shared key through power cycles (Heartbeat can unlock SED but SED can NOT use it’s copy of heartbeat key alone to unlock SED)
• Heartbeats are sequenced
• Heartbeats have a payload which includes read / write transaction count which matches with SED

Below is an image that illustrates Crypto-Heartbeat at work:

In essence, Crypto-Heartbeat flow consists of:

• The trusted session starts with the login to SED
• The trusted session can be short or very long
• The trusted session ends if the host (OS instance) ends, typically as a result of shutting down the computer. However, for example, it still continues after sleep,
• It is violated if other OS instances use the SED (e.g. protocol injection)
• The concept of trusted session addresses potential future attacks!

Crypto-Heartbeat allows the SED to effectively mitigate the 4 SED attack methods discussed at Black Hat Europe 2015, as this innovation is able to recognize when it is being attacked and no longer part of its initial trusted session. With this forward-thinking innovation behind it, SEDs will continue to be the superior encryption technology available to today’s enterprises.