Open Cysioland opened 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.
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.
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:
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".
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.