03-23-2014 09:49 AM
Hello, have a M500 120GB mSATA and have a few questions about the OPAL Encryption support,
a) If I don't "take opnership" (TCG speak for changing the default Admin SP password) of the drive what would stop a virus/trojan/etc from performing the documented steps and locking me out my data?
b) Is there some type of failed attempt counter that sets the SP to a failed state (returns status 04) when a number of failed commands has been reached in a specified perion of time?
c) The Discovery 0 response from the drive indicates that comID management is not supported in the Tper functions segment but the OPAL 2 segment shows the base comID as 0x1000 which is documented as in the range for comID management in table 9 of the OPAL 2.00 specification. Is 0x1000 supposed to be a static comID, if not what is the static comID supposed to be?
03-23-2014 03:58 PM - edited 03-23-2014 05:35 PM
1. If you set an ATA Security password using the BIOS hard disk password, then the OPAL commands are disabled until you clear the hard disk password again.
2. Similalrly, if you activate OPAL/eDrive, the ATA Security commands are disabled until you perform a PSID RevertSP.
So, for #1, you can easily block malware from messing about with the OPAL commands and then, later, activate OPAL if/when you want to by removing the ATA password.
For #2, you can block malware from utilizing the ATA Security commands by activating OPAL/eDrive with Windows 8 or a third-party toolset. Windows 7 also security freezs SATA-attached drives on boot and Windows 8 does the same for SATA-attached drives whenever it sees them, even when hotplugged. However, as far as I am aware, there's no way to completely revertsp crucial's drives because they haven't provided a utility to do so, so you'll never be able to use ATA Security again until they or a third party comes out with software to activate the PSID RevertSP process. Or you RMA the drive.
PS - it's likely you won't get that level of tech info from crucial in the support forum. If you're working on a commercial software application, there might be some developer support program that'll interface you with the right internal folks.
03-23-2014 06:21 PM
Thank you, that covered 1 & 2 very well. I wasn't aware of the security freeze but it certainly stops the malware and explains the issues I'm having sending security commands to the drive. It looks like Linux does a similar freeze but you can disable it with boot flags/ proc
It's not comercial software, just an Oh that should be interesting project.
03-24-2014 05:16 AM
I assume you're using Linux, so things might be done differently there but also note that the security freeze in Windows only happens to SATA-attached drives.
A little trick I learned from watching txbench's behavior regarding Secure Erase on Windows: drives connected via USB are not security frozen by Windows. Depending on the bridge, you can wrap the ATA Security/ATA Sanitize/Opal commands in IOCTL_SCSI_Pass_Through via the 0x85 "ATA Pass Through" SCSI command. Older USB bridges do not properly handle SCSI's 0x85 "ATA Pass Through" command send that way, but newer ones do. So, basically, Windows does not prevent you (or malware) from zapping USB-connected drives with the security command set (unless you've already password protected them, but then you'd need a user-level program to unlock them if you connect them via USB).
Then again, malware that can send ATA commands can also just format the drive anyway...
03-24-2014 08:10 AM
I wasn't working in Linux but I will be........
I've been doing some research and see that Win < 8 also doesn't freeze hot-plugged drives. That would be a wonderful user experience.
I had planned on using SCSI PASS THROUGH but it was failing badly. Interestingly though ATA PASS THROUGH DIRECT sometimes lets a trusted receive slip through and I get a response from a Discovery 0 request. Not sure what that says about SECURITY FREEZE but it really lead me into a blind canyon because it worked SOMETIMES, always a great thing when your debugging.
Yep, theres always a way for the blackhats to get to you, the encryption thing was different because it held the option for ransom ware (WE HAZ ENCRYPTED UR DATA, WANNA BUY THE KEY?) and that would have caused some interesting showboating by both business and political hacks.
Thanks again fo the education and help!
03-24-2014 08:22 AM
03-24-2014 10:36 AM
As mentioned, I've had good luck with sending ATA commands via Windows SCSI Pass Through using the SCSI ATA Pass Through (0x85) wrapper on some recent USB chipsets (usually USB 3.0, but at least one 2.0 chipset also worked). On older USB 2.0 chipsets it always fails.
And right - Windows 7 only security freezes SATA drives during the boot and hibernate-resume processes. Perhaps also after waking from certain sleep states as well? Windows 8 security freezes SATA drives whenever they get connected. Trying to support freezable commands on Windows 8 requires hotplugging just the power, which is probably unwise and always unreliable.
I'd already moved my development machine to Windows 8, so I moved my development toward supporting USB-attached drives with mature and well behaved bridge chipsets. In addition, eSATA ports are disappearing fast.
It's worth noting also that my past experience (under XP) doing some work with SCSI Pass Through (and helping others with debugging) leads me to believe that data alignment *really* matters and you can get odd success/failure patterns because while you're technically aligning your buffers in memory correctly by the Microsoft documentation, the chipset(s) that you are communicating to the devices through have more strict alignment requirement than Microsoft itself documents for the commands. I saw symptoms like code working all the time for SATA and USB-attached drives, but failing sometimes/always for most firewire attached drives (perhaps due to Firewire being a full-time DMA peer and not being managed by the support chipset, and thereby having its own ruleset). Also, similarly data buffer size min/max values and size granularities. For example buffer size must be an integer multiplied by 8 bytes in size. So a 24-byte buffer is OK, but a 28-byte buffer fails for certain bridges/interfaces. Or the pass through commands handle buffers larger than 32kb or 64kb, but the bridge chipset does not and hasn't told the OS about it.
For what it's worth, I'm planning to put my core code (if it works reasonably well) onto codeplex or something similar when I'm done. As posted elsewhere, I'm concentrating on support the security command set commands (password set, clear, unlock, secure erase, etc.) first, then the sanitize command set and, and if it's simple enough to implement, the subset of OPAL commands that allow for a PSID RevertSP.
Let me know if you're planning to do something similar as open source. And if not, let me know about any other problems you run into.
03-24-2014 12:26 PM
Yes, backup early and often.
I thought about alignment being an issue but I decided it wasnt when I reached the 512 byte boundary, I decided/hoped anything that need to be alligned on a bigger boundary would certainly be called out.
I'm looking to use linux as the PBA base (and now the config environment since Windows wont play nice) so my universe will be anything that is supported via the scsi generic/ block scsi generic command set(s), that covers most of the internal drives out there not sure about USB though. I'm sure there will be issues with kernel support but I won't have to deal with them other than follow the bugs.
I'm trying to implement a minimal OPAL enable/manage package. I'm starting with the application notes that the TCG published and will develop a simple PBA image to unlock the drive and then hopefully chain boot into the real OS. I want it to be free for non-comercial use, not sure about open source. I'm not a fan of the licensing issues that crop up with GPL et. al. but then I'm really not looking to get rich or famous with the code so who knows. The PSID revert would certainly fall into that domain, and the TCG claims that erasing an OPAL drive is as simple as changing the encryption key, but I haven't seen what if any standards they claim that will satisfy.
Now back to fighting driver issues in Linux
PS if you want to keep in touch let me know and I can PM you my email address.
I hit spell check but nothing seems to happen so forgive any errors.