I think a few additional words are needed. If someone is reading this topic (at least I hope there are a few of us) he will be able to get an idea what is all about and why we are asking all over again about such "irrelevant" things like ATA and AES keys linking.
The manufacturers are to blame. When Security Extensions to ATA specification was born the manufacturers (like Seagate, Western Digital, Hitachi etc) started a very strange thing. They started to implement unofficial undocumented ways to talk to his drives - so called Vendor Specific Commands which allow to run disk diagnostics and other firmware and S.M.A.R.T related tasks even if ATA passwords was being set so even when device is locked! Why? I don't know but If you ever wondered what actually all those ATA Password Recovery firms want your 50 bucks for, this is it. The hackers quickly started to explore the possibilities and here you have it: you can recover ATA pass from the most of todays drives, you can dump service blocks, inject your modified firmware, you can even dump the locked drive sector by sector from top to bottom. This a pathetic disaster security wise!
I'm fresh to this things but it is beyond me why the manufacturers did not implement some public kill switch passwords which when executed resets ATA security systems and at same time triggers unavoidable Secure Erasing all data on the drive? No more is required! Data still safe and you-manufacturers have your unlocked / servicable drive again, and no more whining that the drive is locked so we cannot service it for you.
Instead they started to build bridges above their own security systems and explaining that they are for service porposes. Don't get it. Locked means locked, doesn't it?
And here is the thing: Even if intel implemented ATA password system in a traditional way (full of holes and service backdoors), even if it is fundamentally flawed there is still hope that the whole thing is secure.
When ATA password is cryptographically linked to AES keys and when it's presented only in a hashed form internally for authorisation purposes, then even if hackers reverse-engineer the controller down to VHDL level and run it in virtual machine 1000 times faster, even if they dump all the registers, they still do not get the final AES key so cannot decrypt the drive.
But if these two conditions are not met (protecting ATA pass with certified hash alghoritm and binding it with AES)... I'm giving you, intel 3 months until this system is defeated. Knowing how leaky the ATA password system is.
I am also watching for the response to the questions. Everything I have read thus far has providied conflicting information as to the actual security provided by the FDE encryption found in these drives.
It basically comes down to this.
The ATA password (master or user) is cryptographicaly linked to the AES encryption key
The ATA password is stored as a non-reversible hashed value in the SSD for authentication purposes
The ATA password is the same as previous platter drives, and is trivial to bypass
I'm looking for a drive, capable of true user-unique FDE, that is non-trivial to bypass. I see in the intel specs reference to "user-unique" encryption available if the ATA password is set, however I do not find confirmation of this anywhere.
I do not want a drive that pretends to implement AES encryption, or implements AES encryption, but leaves the keys hanging from the lock.
I need answers to these questions before I make a purchase decision.
Thanks for the responce to my original question - looks like we can use these drives with reasonable security (we are not in defence industry etc) at least for the machines with support for BIOS HDD.
Do any reader of this thread know if there exists any other solution for FDE SSDs for portables without BIOS HDD password support?
At the 2010 Storage Developers Conference Mr. Dmitry Obuhkov of Sandforce gave a presentation entitled "The Seven Myths of SED" (SED; Self Encrypting Drives). The links for this presentation are very lengthy: Google Obuhkov Sandforce. Myth number two was "ATA security is enough". He stated that "ATA Security + Encryption, This might be enough for simple use cases." The implication is that an ATA password provides only a modest amount of data protection.
Samsung recently released a new version of their encrypted SSD. Significantly, they are not relying on ATA Passwords. They state "The Samsung SSD supports a variety of management software. SSD’s self-encryption and management software work together as essential parts of a fully managed hardware-based encryption solution."
If you require that data stored on your drive being completely protected it appears that third party software is going to be needed in order to restrict access to your disk. Intel's contention that data is secure because AES cannot be broken is absurd when you consider the insecurities inherent in ATA passwords.
It is up to the user, as always, to determine how much security is good enough. ATA passwords may or may not work for you. For now, I personally am staying with an HDD and Truecrypt.
We've put some time into satisfactorily answering your questions. Thank you for your interest; hopefully these help. The questions are bulleted and the answers are in bold underlined text. Have a great weekend!
-Scott, Intel Corporation
ATA Password is stored in media as a non-reversible hashed value. This answer also applies to other questions in the blog. See below.
Unplugging the drive does not unlock the drive, it just removes ATA SECURITY FREEZE LOCK. In order to secure erase the drive, the SECURITY FREEZE LOCK needs to be removed and after that, drive needs to be unlocked using a master/user password.
All data contained(this includes user and system) within the components is encrypted.
See answer to this in a previous question.
Warranty is not valid since SSD works per specification. It is not serviceable by Intel.
Any tool that issues an ATA SECURITY ERASE UNIT command (Secure Erase) as normal or enhanced mode will be able to secure erase an Intel SSD. However, user must provide the correct password (User or Master) within the SECURITY ERASE UNIT command to unlock the drive before doing secure erase.
Intel will ship the drive with random keys. User has the responsibility to enable security state and set their own passwords themselves to get the benefit of the security features. Third party tools such as HDAT2, HDPARM can be used to set master/user password if user system does not have the capability to set them.
Yes, ATA password is used to encrypt the encryption keys stores on the SSD.
Yes, even during power off data is kept in encrypted form. On the other question regarding dependency on ATA password please refer to earlier answers.
Thank you very much for explanation. Just two things, if I may:
1) is this applied also in 510 SSDs?
2) you said that ATA password is used to encrypt the encryption key. That means, that you cannot change the ATA password after it is set for the first time, right? Because if you do, the encryption key will be different and cannot decrypt the data stored on chips.
Thanks for the response!
It resolved most of the doubts.
I'm wondering if there is any possibility to add ATA password support without modifying motherboard's BIOS?
Is there any hope for the very large group of potential intel's 320 ssd users whose desktop or laptop systems and BIOSes do not offer appropriate password interface?
Good reading, Shiek. Thanks.
I can see one rather big glitch in using ATASX (or similar) extension.
It does not work in AHCI mode, unfortunately. It can't see the drive if AHCI is enabled in BIOS.
Running ssd in IDE (legacy) mode is not a horror by any meens but... you are loosing hot swap and more importantly raid functionality for all drives connected to intel motherboard chipset sata controllers.
Unfortunately setting controller in RAID mode in BIOS effectively turns AHCI on. And AHCI becomes turned on for all devices even if ssd is not a part of any raid volume. If I'm wrong here, please correct me.
SSDelightful mentioned about two utilities: HDAT2 and HDPARM. AFAIK they also require IDE mode. They are useful to set the password system on/off but not for everyday authorisation purposes.
Do you have guys any ideas?
This whole matter becomes more and more frustrating.