01-07-2014 03:00 PM
TrueCrypt potentially exposes unencrypted data because of SSD wear-leveling.
I cannot set up Hardware-Encryption on the m500, and the m4 doesn't have hardware encryption.
Does Bitlocker, using Software-Encryption, have the same weakness as TrueCrypt on the m500 or m4?
01-10-2014 12:11 PM - last edited on 01-10-2014 12:55 PM by Crucial_Katana
Thanks for contacting us today. If you configure the software encryption to encrypt the entire drive then you will have no issues with the wear leveling. Hope this helps. Have a wonderful weekend.
01-10-2014 06:54 PM - edited 01-10-2014 07:18 PM
01-11-2014 03:13 AM
I don't get that. Why would wear levelling affect whether your data is encrypted or not?
The only situation I can envisage where people might think wear levelling has an effect would be where the drive has moved some static data from a heavily used block to a less used block. And the assumption is that data in a heavily used block is no longer there at the OS level so wouldn't be encrypted. However, any modern SSD will have erased that data because to not have done so would hurt its write performance. And unlike on a HD, erased data isn't recoverable on an SSD. I can't see how there'd especially be a wear levelling security risk?
01-11-2014 11:34 PM - edited 01-12-2014 12:09 AM
01-12-2014 03:24 AM - edited 01-12-2014 03:38 AM
I'm not sure what you mean by "the assumption is that data in a heavily used block is no longer there at the OS level so wouldn't be encrypted." I always assumed that the OS is agnostic to wear-levelling. That being the case (and correct me if it's not), then the OS doesn't know if the SSD happened to rewrite data somewhere else for whatever reason, be it for wear-levelling or the phenomenon of write amplification in general. AFAIK, you cannot guarantee that the SSD will have erased any rewritten data before being encrypted, and it is that rewritten data that can potentially be exposed.
What I mean is the OS tells the drive to write some data at block A, the drive decides to store it at block G for dynamic wear levelling reasons. Now lets say this data is either little used so the drive later moves it to block P via static wear leveling, or its overwritten and the overwritten data ends up on P. Either way G is now unused. The OS still thinks it's at A and asks for that to be encrypted which the Flash Translation Layer will map to P for encrypting. The only potential security hazard in this I see, is that the data remains unencrypted in G. But aside from any firmware bugs, any SSD beyond the gen 1 drives would be quickly erasing that to prevent the drive getting 'dirty' and crippling write performance. This is beyond the encryption software makers control so they can't guarantee this data is secure.
01-12-2014 09:33 AM - edited 01-12-2014 09:35 AM
01-12-2014 09:53 AM - edited 01-12-2014 10:04 AM
I think that original question was answered by YogiH but I wanted to put my two cents in, from ordinary end-user of TrueCrypt point of view.
I think that roba was refering to this article. There is an assumption that multiple "versions" of a single sector may be available to an attacker. When you change an encrypted volume password/keyfile(s), the volume header is, under normal conditions, overwritten with a re-encrypted version of the header. On the SSD however it is unsure if the older header is really gone or could it be found on the drive. Then if the attacker would find the old volume header (which was to be overwritten) on the device, he could use it to mount the volume using an old compromised password.
Well... if the attacker would obtain access to both your drive and old passwords then I would probably say you might have more serious issues than wear-leveling
Similar scenario would probably apply to a encrypted file container and moreover the attacker would possibly try to find some unencrypted data (stored in the container) by searching of residues of swap file or similar data stored on the device I guess.
In general I agree with clifforama in that with full disk encryption there should be no unecrypted data on the disk - all data is encrypted all the time, swap file, hibernation file, everything. So there is no unencrypted data behind that could be revealed with wear-leveling thing I think. The problem with TrueCrypt's full disc encryption is that it writes data to the entire disk. I didn't check that and I would have to verify that but I believe the part of the drive that is empty (contains no data, zeros) prior the encryption would show some random-looking data after encryption. If that would be true that would mean that from the SSD-controller's point of view you have completely filled your SSD with data. While I would probably try that on the drive like M500 (with factory overprovisioning) I don't know how would that affect the drive like M4 (with no overprovisioning). It would be very interesting to test that
The other possible issue you could face there would be TRIM operation. TrueCrypt advises disabling TRIM for encryted volumes.
By the way it is possible to extract and rebuild the contents of the NAND chips, some proffesional data recovery centres are able to proceed with that kind of recovery and it is relevant to limited selected SSD controllers they have procedures for. It depends on how close particular SSD controllers and/or SSD drives manufacturer cooperate with particular data recovery centre. If they would be able to "rebuild" the content of the TrueCrypt encrypted SSD drive next they would have to try to brake TrueCrypt encryption itself anyway
01-12-2014 12:53 PM
Are you sure that when data is copied from A to G to P, the prior locations are erased along the way? Because if I'm not mistaken, SSDs can't just erase data in the same way HDDs do. So, by the time data has been copied to P, it may still exist at A and/or G until the SSD decides to wipe those locations. And if the drive has plenty of free space, or has other less used areas, it may not wipe those locations anytime soon. But that's just speculation on my part. If in fact you are certain that those locations will be wiped immediately, then the risk is greatly reduced. Perhaps not quite non-existent, but low enough to be negligible (if it weren't already negligible).
I would have thought that it's precisely because SSD's can't overwite data like a HDD that known deleted blocks are erased as soon as possible when the drive is idle. On a HDD you can have data marked as deleted and overwrite it at will. On an SSD it must be pre-erased first. With very early generation SSD's this crippled write performance after the whole drive had been used once. And so things like Trim were invented so the OS can tell the drive it needs to erase blocks that the OS considers deleted. And certainly a Trim command is carried out within seconds of you sending it to an otherwise idle drive.
And then we have Garbage Collection which is more relevant to the wear levelling side of things. We don't know precisely when this stuff happens, but likewise the drive doesn't know when the user may need to write a ton of data to the drive and it makes no sense for it to leave areas of the drive randomly dirty if it happens upon idle time to deal with it.
I guess the best practise if you don't fancy wiping the drive before encryption would be to give Garbage Collection a good run before encrypting? http://forum.crucial.com/t5/Solid-State-Drives-SSD
01-12-2014 01:03 PM
I guess though there is an element of uncertainty that means that if you're having to worry about this your data is probably sensitive enough (I know you clifforama had stated yours wasn't) to warrant hardware encryption. And more guards on your embassy walls.