10-22-2013 09:03 PM - edited 10-24-2013 09:04 AM
Below is my full-length question, but as it gets pretty long I'll do a tl; dr here :
Thanks already !
I've just acquired an M500 120GB mSATA SSD to use in a Clevo W540EU notebook as the boot/system drive, along with the provided 1 TB HDD for data. My plan is to set up full disk encryption on this notebook, while using only GNU/Linux OSes.
I just read the Knowledge Base article An introduction to the encryption features of the M500. Thanks Crucial_Katana for those useful precisions, but would it be possible to have more details concerning the implementation of M500's hardware encryption feature and its interactions with other systems than Windows, GNU/Linux in particular? I discovered a thread at Intel communities website nuancing the efficiency of hardware encryption. It seems that depending on the implementation of the feature, decryption ATA password is stored not-so-securely on the drive (see https://communities.intel.com/thread/20537?start=1
I read in another KB entry (The Advantages of Hardware Encryption) that "Crucial SEDs also support the standard full disk encryption protocol through the ATA-8 security command feature set". Does that mean that a utility like hdparm (available on both WIndows and GNU/Linux) would be able to enable the hardware encryption capability, for example by toggling the
--user-master u --security-set-pass
In my case it seems that a standard BIOS procedure (setting a disk password in "Security/Advanced" section > "Set Supervisor Password" > "Set User/Drive Password" or whatever it may be called in one's motherboard) is not possible with my motherboard/BIOS, an American Megatrends v 2.15.122. I called my notebook vendor and they said it was quite a rudimental mobo, unable to set a SSD password. Hence I'm left with the hdparm way of doing, since I know of no other.
(Indeed searching around the web, I couldn't find a specific GNU/Linux software (except hdparm?) that would handle "the password security feature" mentionned for the M500 encryption in the first KB article. However, I did find a thread at hardforum.com saying that it is indeed by setting the drive ATA password that SEDs are locked and loaded. But is it worth risking to brick my SSD doing so, while I can use classic GNU/Linux software encryption with dm-crypt/LUKS?
The thing is, unlike software encryption, if something goes wrong with hardware encryption then the device is bricked I suppose. There's no way to get it back, the controller blocks access to the disk. Taking the drive out of the first machine and tryi running hdparm to disable the password wouldn't work I suppose (otherwise that would defeat the purpose of encryption). Hence I'm wondering if it is such a great idea to rely on hardware encryption. Since my CPU has support for AES_NI instructions, I'm considering using software encryption, even though it'll conflict slightly with built-it M500 encryption...)
Furthermore, aforementionned "The Advantages of Hardware Encryption" KB post says that "since the encryption takes place on the SED and nowhere else, the encryption keys are stored in the controller itself and never leave the drive". Does that mean that I should do a secure erase of the M500 before using it (again, through hdparm if nothing better for GNU/Linux) to make sure the keys are renewed? This topic is indeed also brought up in the aforementionned hardforum.com thread.
Bonus question : is the maximum length of the SSD's password limited by the drive itself or by the BIOS/software that sets it? Is it a 32-byte standard ASCII password string or is there some kind of built-in limitation for the Crucial M500?
Cheers to the community, I'll wait for the replies!
Thanks for your replies! :-)
11-02-2013 08:15 PM
I have the exact same questions. I am also trying to use FDE in Linux. My motherboard also did not support a HDD password. I've been playing around with hdparm but I haven't figured out how to get anything to work except for --security-erase. One additional question I have is about booting the disk. Will the "shadow disk" boot up if the drive has been correctly encrypted and locked? I am also wondering how to lock the SSD using hdparm or if locking is even necessary. I have been scouring the web to find answers, but I have found very little. I'm hoping this post can be answered!
11-05-2013 06:34 AM
I have had a look in to these questions for you.
The hardware encryption on the M500 is compatible with Windows 8 bitlocker, Wave and WinMagic. This means that hdpram is not going to use the hardware encryption and I am unaware of any Linux based options for this.
With regards to the security of SED, this provides verified and certified data security which offers nearly unbreakable pre-boot access protection for user data. Because SED access is pre-boot, there is no possibility of running an OS utility to break authentication codes.
The SSD password limitations are to do with the software as you are directly dealing with the software when imputing the password to the drive.
12-10-2013 06:03 PM
Hi, and thank you for your answer. Sorry it took me so long to reply, I thought I had been automatically subscribed to this post since I wrote it, but apparently it wasn't the case.
Thank you for your confirmation about the unavailability (to your knowledge) of a software able to manage OPAL compliant drives on GNU/Linux. I had given a bit more effort to this quest, going as far as trying to contact WinMagic for their SecureDoc product, but besides the latter being non-libre software, the company is so much geared towards the "entreprise world" that they refuse to be contacted through their website without a "non-free" email addres (no gmail, no yahoo... Anyway). Nonetheless, I left the question opened here: http://security.stackexchange.com/questions/45542/
Concerning the other part of your answer, saying "This means that hdpram is not going to use the hardware encryption", when my question was about setting the ATA password through the use of hdparm, translates into "Setting up an ATA password won't trigger the encryption features, i.e. the ATA password is not used to encrypt the encryption keys" right? Saying this translates into "M500 SSDs don't support the ATA-8 security features", am I mistaking? If it is so, why can we read in the aforementionned Crucial KnowledgeBase article:
"Crucial SEDs also support the standard full disk encryption protocol through the ATA-8 security command feature set"?
That sounds rather contradictory to me... Although I can see this is a consistent answer given on those forums, as seen in Unable to set Drive Password for M500 - Crucial Community. Can we have an explanation about this discrepancy?
I'm gonna throw an idea that I'd be delighted if you transmitted to whom it may interest within Crucial : why not provide customers with a liveCD/USB image (.iso file, such as the ones used for firware upgrades), that would allow them to boot from it and activate Crucial's SSDs hardware encryption feature? No fancy stuff, doesn't even need a graphical console, just to offer the ability to set up a password (which should be ATA password, but anyway) which would then arm the drives' encryption. And, occasionally, change said password or unarm the encryption feature (so as to repurpose the drive by reselling it as second hand or handing it over to family, etc.), after correctly exposing an interface to first decrypt it (yeah, nobody wants a utility that can so simply circumvent drives' hardware encryption)...
Woah, now that would make a commercial argument. "No need to wait for Independent Software Vendors to care about end users, Crucial is taking a lead in the field of consumer data protection: after being one the first to offer OPAL 2.0 compliant drives, they're now shipping a small and simple utility to actually use this feature!". Beautiful world.
I hope this will reach any sale strategy brainstorming that Crucial may have. ISO format --> OS independent, already used for firmware upgrades (same level of technicity required). It would only work with Crucial's drives, by virtue of recognizing the drives' (name your preferred identifcation method, serial number of whatever).
Thanks anyway for the discussion.
PS : Slightly off-topic, but when you say -- thus copy-pasting this entry from Crucial KB -- "Because SED access is pre-boot, there is no possibility of running an OS utility to break authentication codes", that is somehow hiding the fact that one can boot on an external device such as a USB key, and then run an OS utility to try to break authentication codes... Here I'd rather use the argument of a valid implementation of AES 256 bits. Or does this actually mean that with SEDs one cannot do rescue operations from a live system, as it's been possible with software full disk encryption for years? Hmm, reconsidering ever using hardware encryption...
12-16-2013 07:58 AM
Thanks for your reply.
I have to clarify a few things in your post before I can answer all your questions. As soon as I have heard back from our tech team I will let you know.
Thanks for your patience with this matter.
12-17-2013 08:06 AM
02-10-2014 08:24 AM - edited 02-10-2014 08:24 AM
Any news on this? There doesn't seem to be a definitive answer yet.
I want to buy a Crucial M500 for its full disk encryption capabilities, but I use Linux and my motherboard doesn't support ATA password in the BIOS. Will I be able to use FDE with my own passphrase? How?
04-20-2014 04:23 AM
Neitsab, thank you very much for your detailed questions. Your concerns are mine, but I would not have been able to express them as precise as you.
However, as there are no further answers from Crucial, I have to assume that you found the security holes... so this time, I will refrain from buying Crucial. :-(
Dear Crucial guys, if you manage to clarify the remaining questions, I would consider buying (and recommending) Crucial next time!
04-20-2014 09:30 AM
tpt, it is my pleasure to see my question may be useful to others. I had undertaken quite a bit of research at that time and I'm happy it didn't completely go to waste :-)
As you underlined no further response from Crucial arrived in a while, and therefore we can conclude M500/OPAL encryption management on GNU/Linux won't be landing anytime soon.
Since the beginning of this journey to security-land I have learnt not to rely on a unique source for my crypto needs, and therefore discarded harware-based encryption mechanisms alltogether realizing how blackbox-y they were.
Since my processor supports AES_NI instructions I went the dm-crypt/LUKS way and am fully happy with it. It leaves my system vulerable to "Evil Maid" type of attack but that isn't so much of an issue for my security model.
I must say that for people planning to use software encryption with the M500, they'd be better off buying a drive with no hardware crypto at all so that it doesn't interfere/double up with software one (which can lead to some slow-downs and maybe precocious tear on your system). I would have known the mess it was gonna be before buying, I think I wouldn't have gone Crucial/M500's way.