Drive-Trust-Alliance / sedutil

DTA sedutil Self encrypting drive software
611 stars 236 forks source link

Duress password #32

Open Cysioland opened 8 years ago

Cysioland commented 8 years ago

It would be nice if PBA implemented a feature, where you set a second, special password, that upon its entry, the PBA would revertTper, and thus destroy the data residing on disk.

r0m30 commented 8 years ago

I'm going to label this as an enhancement request. I think it could be implemented using the PSID, using another authority/password would expose that authority/password if the drive were removed from the computer or the computer was booted from a different drive. but even using the PSID could end up being problematic as it could expose the PSIS and allow malware to us it to erase your drive.

zviratko commented 8 years ago

I have a pretty old Thinkpad T510, and theres a "BIOS extension" for it to support SED drives. All it does is enable erasing the drive from what I can tell. I tried it and BIOS is able to restore it to factory (the same way yesIreallywanttoERASEALLmydatausingthePSID does it). Might be an Opal1.0 thing, though as my drive seems to support both Opal 1+2.

sdca commented 6 years ago

The PSID can be encrypted with the duress password so malware can't access it.

There are some flaws though when it comes to detection:

  1. The partitions/appearance of a locked drive would have to match exactly after the duress password is used. You would have to use the PBA on another drive like a USB stick, as any on-device PBA would be wiped too and take too long to re-install. The drive would have to be immediately re-locked with a random key.
  2. If a clever MITM attack is deployed, someone can find out that you've typed a duress password and the drive won't be wiped.
oom-is commented 4 years ago

I was thinking about this with a different approach. First step would be to install a very small reasonably-functional Linux distro in the shadow MBR area that normally contains the PBA. My thought was Tiny Core Linux - easily fits inside a 128MB shadow MBR area. That addresses the (commonish) case at international crossings/transit where someone wants to see the computer boot, and allows booting without actually giving real access to data on the drive.

Then, re-install the Linux distro in the PBA but include two different new binaries within the installed "Linux within PBA" - one with an attractive name and the other with an innocuous name. The second would be the actual sedutil-cli renamed, while the first would be a specially compiled utility that has the PSID for the drive hard coded into it, and when executed (regardless of command line arguments) it always does a full PSID revert/crypto erase. (Even if a bad guy gets my laptop and boots the Linux PBA and knows Linux, there's a high probability that they'll run /usr/bin/driveunlock before they try /usr/local/bin/ddir.)

The proof is left to the student, and it's not proof against all worst-case scenarios but it's perhaps a reasonable start towards a "deadman switch".