M500 hardware encryption with GNU/Linux

Kilobyte Kid

M500 hardware encryption with GNU/Linux

[ Edited ]

Hello everyone,

 

Below is my full-length question, but as it gets pretty long I'll do a tl; dr here :

  1. Is Crucial's way of implementing hardware encryption really secure, unlike Intel's one?
  2. Is it possible to use Crucial M500 hardware encryption feature with the hdparm utility under GNU/Linux? If yes, how should that be done? And should I issue a secure erase command beforehand so as to renew the encryption key?

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=105&tstart=0). What about Crucial's way of implementing this technology? Can we be told more? Do the security certifications of the disk cover a specific way of implementing ATA password storage?

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

 

params?

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! :-)

8 Replies
Kilobyte Kid

Re: M500 hardware encryption with GNU/Linux

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!

Highlighted
Community Manager

Re: M500 hardware encryption with GNU/Linux

Hi guys,

 

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.

 

 

Junket, Crucial Moderator UK
________________________
How do I know what memory to buy?
Shop for your region: US | UK | EU | France | Global
I think my memory is bad. What do I do now?
FAQs and Top Forum Solutions
We want your feedback! Post in the Suggestion Box
Did a user help you? Say thanks by giving Kudos!
Still need help? Contact Customer Service
Kilobyte Kid

Re: M500 hardware encryption with GNU/Linux

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/free-libre-software-to-handle-tcg-opal-2-0-complia...

 

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...

Community Manager

Re: M500 hardware encryption with GNU/Linux

Hi Neitsab,

 

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. 

Junket, Crucial Moderator UK
________________________
How do I know what memory to buy?
Shop for your region: US | UK | EU | France | Global
I think my memory is bad. What do I do now?
FAQs and Top Forum Solutions
We want your feedback! Post in the Suggestion Box
Did a user help you? Say thanks by giving Kudos!
Still need help? Contact Customer Service
Kilobyte Kid

Re: M500 hardware encryption with GNU/Linux

Hi Crucial_Junket, and thank you for your notification. My posts are long and I appreciate you take the time to ask the tech team so as to answer them, as I appreciate the possibility to communicate with Crucial about its products. Post your answer whenever you can.

PS: one thing that I should add concerning the use of hdparm to trigger hardware encryption (and therefore the issue of ATA passwords relationship to M500's hardware encryption), is that a certain Mark from Crucial with whom I chatted in a live chat session, told me I actually could use the hdparm utility. Here's the transcript from our conversation:

"Me: Hello sir. I'm looking for information about how to use M500 SSD's hardware encryption feature under GNU/Linux.
Specifically, may I use the hdparm utility (available on both Windows and GNU/Linux) to activate it and manage encryption key?
Mark : Yes, you would need a 3rd party program, such as the one mentioned, in order to set a password and allow the encryption to be managed.
Me: Thank you for this confirmation."

So this is another discrepancy to add the our confusion ;-)
Bit Baby

Re: M500 hardware encryption with GNU/Linux

[ Edited ]

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?

tpt
Bit Baby

Re: M500 hardware encryption with GNU/Linux

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!

Kilobyte Kid

Re: M500 hardware encryption with GNU/Linux

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.

 

Cheers