This discussion is locked
1 5 6 7 8 9 Previous Next 124 Replies Latest reply: Feb 26, 2013 10:56 AM by LS1 Go to original post RSS
  • 105. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    Dwarf Community Member
    Currently Being Moderated

    mojo wrote:

     

    @ChemicalX, I don't think you appreciate the implications of what you are saying. If the password hash is stored anywhere then it is insecure, in that it can be cracked with some (perhaps considerable) effort. Take all look at the Truecrypt docs, particularly the section "Header Key Derivation".

     

    That being the case then the encryption scheme is broken. There is a severe security flaw that allows an attacker to break it with consdiderably less effort than should be required, an amont of effort that an ordinary person with a high end graphics card can muster in a few weeks or months maximum. If they didn't properly salt it then it might even be crackable in seconds via rainbow tables, but I'll give Intel the benefit of the doubt there.

     

    Of course it depends who your attacker is. The average computer theif might not bother, but if you keep corporate secrets on your laptop or are at risk from oppressive regeims you had better not rely on it. I think SSD manufacturers have rushed to add secure sounding AES encryption because Sandforce did it, but it isn't actually anything like as secure or useful as it sounds.

     

    It is possible to design a EEPROM chip that couldn't be read on modern level of science and technology. Take a look on FIPS 140-2 standard. But the question is WHY Intel stores the hash of ATA password in drive controller? Why not just to encrypt the main volume key with this password as TrueCrypt does? Or it least store it in plain text if they made a controller with level 4 security FIPS140 standard. Storing the hash of ATA password is completely pointless in every case!

  • 106. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    prowest Community Member
    Currently Being Moderated

    In addition to increasing the performance of the SSD 320 series over the G2, Intel has also incorporated a few new features to enhance reliability and security. Along with using the over-provisioned space to minimize write amplification and for wear-leveling and other drive maintenance, part of it is also used to store parity data to help prevent data loss in the event of a partial or full NAND device failure. The drive also has an array of capacitors that will supply a bit of power in the event of an outage so the drive can flush its cache and complete and pending write operations. The Intel SSD 320 series drive also offers AES encryption to help protect user data.While discussing the features of the SSD 320 series, Intel was also keen to talk about the reliability of their drives and the work that was done to ensure the SSD 320 series was their most reliable drive yet. One of the slides above shows the miniscule failure rate of Intel’s solid state drive offerings in a variety of deployment scenarios. Intel hopes the SSD 320 series drives, despite the fact that they use 25nm NAND flash which is more prone to failures than 34nm NAND (as process geometries go down, NAND is more prone to errors), will be their most reliable yet. Of course, we won’t know until the drives have been shipping in volume for some time, if this turns out to be the case, but reliability was clearly a strong focus for Intel with this series of drives.

  • 107. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    curiouscat Community Member
    Currently Being Moderated

    @ryan29: Thanks for the information about your Gigabyte motherboard and booting the encrypted drive. I have a DS3 I'm going to try that on. I also have an ASUS P8Z68 I'm going to try, probably later this month.

     

    @all:

    The ATA password is probably stored as a hash to meet the standard. I believe Intel firmware has to verify it has the correct password and they use the hash to do that. As I said earlier in this or another thread the real question is what hash they're using for that. Conceivably we could choose 32 random characters for our ATA password and that random data is used to make the hash. If it's an sha256 hash, well that's ok with me. If you have only 32 characters of input on a one-way maybe there might be some attack for that specific situation? But if it's some xor magic with md5 that's not ok with me.

     

    The bigger elephant in the room for me right now is this 8MB bad ctx crap it needs to be addressed yesterday. We need more "Intel" on the causes and solutions. Yeah, I'm corny.

  • 108. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    Dwarf Community Member
    Currently Being Moderated

    @all:

    The ATA password is probably stored as a hash to meet the standard. I believe Intel firmware has to verify it has the correct password and they use the hash to do that. As I said earlier in this or another thread the real question is what hash they're using for that. Conceivably we could choose 32 random characters for our ATA password and that random data is used to make the hash. If it's an sha256 hash, well that's ok with me. If you have only 32 characters of input on a one-way maybe there might be some attack for that specific situation? But if it's some xor magic with md5 that's not ok with me.

     

    The disk volume is encrypted by master key. This key generated during secure erase command and do not change when you change ATA password. That's why you can set password in seconds it because the volume is already encrypted. And because of this you can proceed secure erase in one second its because you need only change master key and the volume became a random garbage without the knowledge of previous key. Ok? This scheme is in use by most full disk encryption software.

     

    Now the question is how this encryption key is stored?

     

    1) It could be stored on insecure chip but encrypted by ATA password. When you set ATA password, controller encrypt master key with this password and store it in insecure EEPROM chip. Then you need to provide ATA password to read the volume because master key is encrypted and couldn't be used to decrypt the volume. But in this case ATA password is not stored anywhere.

     

    2) It could be stored on secured EEPROM chip satisfying the level 4 of FIPS 140-2 standard. In this case controller can be used as an oracle. Nobody can gather information from this secured controller. You can only plug it on and provide correct ATA password to read encrypted volume. In this case controller store master key as a plain text. And ATA password could be stored as plain text as well.

     

    Is it clear? When you need to use hash??? In what case?

  • 109. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    mojo Community Member
    Currently Being Moderated

    Exactly, the design makes no sense. I think either SSDelightful is wrong or the system is not designed to be secure at all. I think the most likely case is that the password is not actually used to encrypt the drive key at all and is merely an ordinary password that the drive requires before it will allow further access. Like most HDD ATA passwords it is probably totally insecure and easy to bypass, meaning there is basically zero protection against anyone who wants the data.

     

    As I said, it's a tickbox feature, basically worthless. As far as I can tell the only company that makes known secure SSDs is Samsung, all the Sandforce ones are as useless as the Intel drives.

  • 110. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    DesktopMan Community Member
    Currently Being Moderated

    Dwarf:

     

    In your case 1 you would actually need to have a hash of the password, how else would the drive know it's correct? Encryption doesn't fail if you try to use the wrong key (if you decrypt the master key with a wrong ata password), it just gives you different data.

  • 111. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    Dwarf Community Member
    Currently Being Moderated

    DesktopMan wrote:

     

    In your case 1 you would actually need to have a hash of the password, how else would the drive know it's correct? Encryption doesn't fail if you try to use the wrong key (if you decrypt the master key with a wrong ata password), it just gives you different data.

     

    Yep! Encryption software uses volume header checksum to verify decryption correctness. But really, full SSD encryption not need any header so your words make sense. But why Intel not to clarify and publish the actual scheme of encryption? I am also interested in internal encryption algorithm, are they use LRW/XTS/XEX algorithm or just simple CBC mode of operation? According to Kerckhoffs's principle Intel should publish all details of there encryption system/process.

     

    Or else any speculation are allowed, and even mojo may be right. For now Intel just say: hey guys we use full disc encryption with AES algorithm and store passwords hashed! Be proud that we are concerned about your privacy, believe us we are professionals! Its just a marketing it is not an encryption system description.

  • 112. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    ryan29 Community Member
    Currently Being Moderated

    I had a bit more time to play around with my disks on the weekend and, regardless of how secure FDE implementation is, I don't know if I'm going to end up using it.  I'm a bit disappointed because a lack of FDE was one of the main reasons I took so long to make the jump to SSDs and the promise of FDE was the main reason I bought Intel drives.

     

    In terms of usability (security related below this):

     

    First off, I can't use FDE on my desktop because my motherboard (Gigabyte P35-DS3R) doesn't support ATA password and none of the alternative methods for unlocking the drive work for me.  Booting into linux with the drive locked, unlocking it and then rebooting adds about 80 seconds (POST + disk timeouts) to the boot process and using IDE mode incurs too much of a performance penalty, so the ATA Security eXtension BIOS isn't an option.

     

    IMO, this is a big problem for the average user:

    SSDelightful wrote:

     

    4.   In order to provide the absolute best security possible, there are no available password recovery solutions.  If you lose or forget your ATA User Password and Master Password, your SSD will remain locked without access to read, write, or erase any data within the device.  In this case, your SSD and your data are lost, and cannot be recovered by Intel.

    Pit wrote:

     

    3. Let's assume that User had set his own ATA User Password and Master  Password and then he forgot both of them. Now he's returning the drive  as broken. Does his warranty still valid? I can understand that ATA  locked device is unreadible, unwritable and unerasable. But is it unservicable?

    SSDelightful wrote:

     

    Warranty is not valid since SSD works per specification.  It is not serviceable by Intel.

     

    Here's an example of someone that has a bricked drive because of a problem that shouldn't exist:

     

    http://communities.intel.com/message/131126

     

    I say the problem shouldn't exist, because the Intel SSD Toolbox should check the 'Master Password Revision Code' (Word 92) and offer to change it as an optimization if it's never been set.  At least that way the (average) user has a BIOS independent way of recovering the disk if the need arises.

     

    Like the poster in the linked thread, I also have a Dell laptop.  I locked the drive, put it in my desktop (which doesn't support ATA password) and tried to unlock it using 'hdparm'.  Dell must transform the password somehow before passing it to the disk since, AFAIK, the ATA password spec doesn't forbid doing so.  That means the password could be padded, hashed, salted or transformed in pretty much any way before being passed to the disk.  I couldn't figure out what it was and ended having to put the disk back into my laptop to unlock it.

     

    Now, I have no problem losing all my data if I forget my password or my laptop sets it to something weird, but to make the drive unserviceable...  The average user might still use the FDE since a bricked drive if their laptop dies is still better than their data being open to casual snooping if the forget their laptop somewhere.

     

    However, if I were a corporate user, I'd be hesistent to buy these if I were tasked with buying drives that support FDE.  Running software based FDE like TrueCrypt or BitLocker isn't a very good option and dealing with forgotten passwords is a huge pain.  Setting a master password negates the issue, but there isn't a supported tool for setting the master password (that I can find) and, worse yet, there's no best practices documentation (that I can find) for dealing with forgotten user passwords.  Do I need to boot into linux, hotplug my disk and use hdparm (this is how I did it)?

     

    I'll likely use a bootable linux disc to set a master password and use the built in ATA password support of my laptop.  At least that way I know I can recover the disk if my laptop dies.  I had to give up on my desktop.

     

    -----------------------

     

    In terms of the FDE implementation, it definitely needs some clarification.

    SSD Delightful wrote:

     

    Yes, ATA password is used to encrypt the encryption keys stores on the SSD.

     

    I'm extremely skeptical of this claim unless there are actually two copies of the AES encryption key stored on the disk.  I booted up my machine with a Debian Live CD and did the following testing.

     

    a) set the user and master password
    b) power the disk off / on
    c) unlock the disk with the user password
    d) mount a partition, access data, unmount the partition
    e) power the disk off / on
    f) unlock the disk with the master password
    g) mount a partition, access data, unmount the partition

     

    I was able to access my data using either password.  So, if a key derivation function (http://en.wikipedia.org/wiki/Key_derivation_function) of some type is being used to encrypt the AES key, there has to be two copies of the AES key stored on the disk; one for each password, right?  Hopefully someone can repeat my test and confirm it just to be sure I didn't screw something up.

     

    The cut and paste from earlier reads a bit different.

    SSDelightful wrote:

     

    The encryption keys are securely held within the SSD device, hidden and encrypted using standard security techniques.  These keys cannot be read by the user.  All Intel SSD 320 Series drives do this.  No user intervention is needed to enable data encryption on the NAND devices within the SSD.

     

    What are 'standard security techniques'?

     

    IMO it's far more likely the user / master password is being used to unlock the disk and the disk won't give up the encryption keys until the drive gets put into an 'unlocked' state.  Then storing a hash on disk makes sense too since it gets used for password verification.  Hopefully I'm wrong.

     

    Maybe the intern that implemented the FDE scheme finished their internship and isn't available to explain how it works ;-)

  • 113. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    mojo Community Member
    Currently Being Moderated

    You can use a BIOS extension for desktops. It works well. http://www.fitzenreiter.de/ata/ata_eng.htm

  • 114. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    ryan29 Community Member
    Currently Being Moderated

    mojo wrote:

     

    You can use a BIOS extension for desktops. It works well. http://www.fitzenreiter.de/ata/ata_eng.htm

     

    That is only IDE, not AHCI and I don't think he plans to update it.  I take a fairly big performance hit when I switch to IDE:

     

    http://imgur.com/a/9Beny

     

    I don't understand BIOS stuff well enough, but I found myself wondering why Intel didn't include ATA password support in the ICHxx AHCI BIOS.

  • 115. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    DesktopMan Community Member
    Currently Being Moderated

    I fully agree with you ryan29. Intel needs to release BIOSs for their boards with ATA password support. I bought an Intel desktop board for this very reason, assuming they would surely have it because of their SSDs.

  • 116. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    ryan29 Community Member
    Currently Being Moderated

    I got more time to play with my disks over the weekend.  In my opinion, implementing AES encryption on top of HDD (ATA) password was a mistake.  There's no way to guarantee your disk is secure without testing the way your specific system implements ATA password.  Others in this thread have already made the point, but I'll give a very specific example.

     

    I have a Dell Studio 1537 laptop.  The BIOS has an HDD password.  As I mentioned in my previous post, I can't figure out what the user password actually gets set to, so I decided to boot off a linux live cd, set a master ata password and then rely on my laptop's built in HDD user password for day to day use.  That way I figured I'd have a way to recover my SSD if my laptop dies and I can't figure out what the user password is set to.

     

    However, while testing to make sure I could actually go back and unlock the SSD after the fact, I realized the master password I set no longer worked.  After a decent amount of testing, I'm fairly sure when I set the HDD user password in the BIOS, the HDD master password is also changed.  My theory is that Dell has things set up so that whenever I set a user password, the master password gets set to something Dell knows so they can service machines that get returned under warranty.  Based on the claims of most HDD unlocking services, the master password is getting set to something that Dell can derive from the service tag.

     

    And that's the problem with building on top of ATA password.  For the vast majority of users, their disk is only as secure as the ATA password implementation in their BIOS.  If the vendor of the BIOS is setting the HDD master password to something reversible, the whole thing becomes worthless.  It doesn't matter what Intel does with the password once it gets to the disk; the system is already broken at a higher level that Intel has no control over.

     

    I can use max security on the disk, but then I'm back to the original problem; I can't figure out how to unlock my SSD using the HDD user password with anything but my laptop.  If my laptop dies, my SSD is bricked.

     

    Besides the shortsighted FDE implementation, I'm actually very happy with my disks (as long as my rebates come thorugh ;-).

  • 117. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    AnybodyM Community Member
    Currently Being Moderated

    SSDelightful wrote:

     


    2.   Support for ATA Passwords within BIOS or other means are system implementation specific. [...] Consult your system manufacturer’s documentation, or contact your system manufacturer for support.

     

    The Intel® Desktop Board DQ67SW, DQ67OW, and DQ67EP support the ATA Password functionality, called “HDD Password”.  On these boards, the HDD password support works in all SATA modes (IDE, RAID, or AHCI).  The HDD password will only be applied to the drive on SATA port 0.

     

    3.   The ATA Password standards, and therefore Intel SSD 320 Series drives, allow for up to 32 byte passwords and contain no specific password “strength” requirements.  32 bytes enables users to create passwords with significant security “strength”.  It has been noted that some systems support ATA Passwords which are significantly shorter than 32 characters in length, and contain no password “strength” requirements.  The utilization of the ATA Password security interface in system BIOS is system implementation specific.  Consult your system manufacturer’s documentation, or contact your system manufacturer for support.

     

     

    @SSDelightful:

    I bought an Intel 520 SSD Drive, among other things because of it's claimed strong AES encryption. I'm using an Intel DH67CL Mainboard which is very similiar to the DQ67 series you mentioned.

     

    This board's BIOS however does not allow setting the HDD Password to more than 8 characters. With 8 characters one can support at most 64bit encryption, more realistically (because not all characters can be typed on a keyboard) it's more like 50-55bits of maximum password complexity.

     

    a) Why does Intel offer a completely insecure HDD Password functionality in it's own mainboards for no apparent reason while promoting the encryption capabilities of it's SSD?

    b) Does the DQ67 series you mentioned allow longer HDD Passwords than the DH67 Series? If so, why is Intel making the H67 based boards artificially insecure for no apparent reason?

    c) When will this be fixed? You mention I should contact my system manufacturer for support. The manufacturer of my system (=Mainboard, BIOS) is Intel (=You)...

  • 118. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    michaelk Community Member
    Currently Being Moderated

    Hi

     

    I've enabled the ATA Password on my PC and everything works fine.

     

    I now want to move the SSD to another PC and remove the FDE.

     

    What is the exact supported procedure to do that?

     

    Are the steps below correct?

     

    1. Reset the ATA password
    2. Dissconnect the drive
    3. Run secure erase on other PC
    4. reinstall/restore OS, apps and so on.

     

    Can I use an sata to usb adapter to perform step 3 above?

     

    I just want to dubble check before doing anything drastic

     

    Thanks in advance,

     

    Michael

  • 119. Re: Intel 320-series SSD and FDE (Full Disk Encryption) questions...
    phil_l Community Member
    Currently Being Moderated

    Hi

     

    To move the drive to another PC remove the password in the original PC first.

     

    You don't have to do a secure erase unless you are giving the drive away, just delete the partitions and start again, in theory running the Intel Optimise function permanently destroys old data.  To do a secure erase requires you to hot plug the SSD into the computer after it has booted so that isn't locked to low level security commands.  To do this connect the power cable to the drive but disconnect the SATA cable, then reboot, once the system has booted connect the SATA drive cable.  I'm not sure if you can do this via USB.

     

    Regards

     

    Phil

1 5 6 7 8 9 Previous Next

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 4 points
  • Helpful Answers - 2 points