03-26-2011 08:14 AM
I am considering to buy a couple of new solid state drives for my company. A requirement is FDE and according to some info I found the new 320 series should support this. I have a few questions:
1. As far as I know none of our computers have any support in BIOS for disk password. Is this required for FDE to work with the 320 series or how exactly does the encyption / password entry work?
2. If we would like to use a RAID configuration (RAID 0 striping) is it still possible to use FDE and if so do one have to enter a password for each disk?
3. What about using two disks in the samer computer (non-raid) that is used to dual boot two different operating systems (say Linux and Windows 7) installed one OS on each drive - does FDE work in this case and would one have to enter a password twice?
4. Is the FDE solution dependent on some support in the OS (in that case what OS does it work with) or is it independent?
5. Do you have some white paper about the FDE with for instance information about how much slower it is compared to a non FDE drive?
6. I have read that TRIM does not work with SSDs in RAID configuration. Is this still the case and how dependent is the 320-series of TRIM?
/Trist
CORRECTION : I just found that our Dell Precision M6500 computers do have a field in the BIOS for disk password so I am interested in the questions above (two disks in the machine with or without RAID) also for this configuration. How do I know if the 320-serias FDE is compatible with the disk password setting in the dell M6500 machines? Is there a standard for this that all BIOS manufacturers follows or??
05-31-2011 12:25 PM
No additional special areas or boot loaders in intel's case as all of them require some area being unencrypted (even if it is really small).
You are forced to use security ATA extension commands to authorize yourself.
Security ATA commands can be implemented in BIOS (hdd passwords - quite rare in desktops) or you can use third party tools: ATASX extension, hdparm utility in linux, HDAT2 in DOS etc. BIOS procedures have advantage of being executed without need of any operating system (quick, convenient), other solutions require OS (booted from other media of course - pendrive or another hdd) to unlock the intel ssd drive.
But all of these solutions are no more then different methods to deliver ATA password to the drive.
ATA password system is not insecure by design. The implementation part used to be an Achilles heel. It could be more secure than preboot authentication for instance as it is resistant to boot code switching hack methods. However only when executed properly of course.
06-01-2011 03:34 AM
Thanks for taking the time to explain further. I'm about to re-read the thread so I might get up to speed this time around..
I've read about the ATASX extension and its limitation and that is about the most convenient way there is.
ATA password might not be insecure by design, but do you trust it? There are no official details about how Intel has implemented this on SSD's. I hope they come forward with more details but, ATM, due legal implications, I'm obliged to provide strong protection for data at rest. Since Truecrypt isn't the best of friends with SSD's, I was hoping to find a good Intel SSD with encryption. I guess I'll have to go with a traditional Seagate drive for now.
Speaking of which, you appear to be very savvy on this subject, would you mind me asking a question about this PDF you linked too?
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1299.pdf http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1299.pdf
06-01-2011 03:45 AM
Intel SSDs do not rely on compression to increase performance so using TrueCrypt on an Intel drive is not a problem. I personally run this setup on two computers, one with an x25-m and one with a 320 model.
Trust is an entirely different issue all together. I would also appreciate more details on how the internals work.
06-01-2011 12:12 PM
Won't TC mess up the wear leveling since all is encrypted, meaning there is 0 free space? At any rate that's another discussion so I'm not looking to lead this one off topic.
06-03-2011 12:19 PM
hi,
i found another bad thing about ata security:
http://www.intel.com/support/ssdc/hpssd/sb/CS-030724.htm http://www.intel.com/support/ssdc/hpssd/sb/CS-030724.htm
after reading the whole thread i was very confident about the ssd but bricking the hardware when changing the pass???
and i've got another question regarding the password hash. i have got a lenovo x200 and the password will be hashed by the bios and then stored at the disc. does the intel controller hash the password again or does the answer from that intel guy mean that password is hashed only if the implementation of the bios said so?
regards