TRIM Passthrough for Encrypted System on SSDs?
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
I have not been able to find any technical information about the implimentation of TRIM in VC or TC. The old TC documentation suggests that TRIM will work on system drives that are running FDE, but there are no specifics or instructions on how to verify that this works in theory, or is working on a particular installation.
The concern is that an SSD which believes it is full will not be able to properly perform garbage collection. If the OS is able to pass through TRIM commands and identify free space to the drive, then garbage collection will continue to run even with FDE protecting all of the data. There are negative security aspects to having the exact amount of occupied space readily observable, but for many this is secondary to protecting the drive and having old data properly removed.
This issue occurs because some FDE programs write random data to the entire drive, whether or not the block is currently in use, which confuses the SSD. Garbage collection stops clearing old data from the NAND because the SSD still sees the encrypted block as being "in-use," even after the file was deleted in the OS. This creates privacy concerns and severely reduces the life of the drive.
Anyone able to tell me how VC addresses (or doesn't) TRIM/GC? Published data, personal experimentation, or links are welcomed. Thanks for your help.
Note: Symantec's PGP Disk Encryption offers this functionality, but not by default. You have to use the "--fast" flag when doing intial setup to tell the software to only encrypt existing data. This --fast flag also tells the software to mark emtpy space as empty, allowing the SSD and OS to work together as if the FDE were not even there for purposes of TRIM/GC.
I thought having some context might further clarify my question. Thanks again.
Found this comment today about TC.
For SSDs, BitLocker appears to issue TRIM commands when encrypting entire system drives, whereas with TC, I would have to do a manual TRIM after encrypting a system drive to observe zeroed sectors when viewing outside of Windows. For SSD data drives, of course, there is no remedy as TrueCrypt doesn't support TRIM on data drives, or more generally, volumes outside the scope of system encryption.
Original here: http://www.wilderssecurity.com/threads/are-you-using-veracrypt-as-replacement-to-truecrypt.374694/
I will install VC on a system drive, manually run TRIM, and would like to be able to verify that it is working like it did in TC. Can anyone teach me how to easily view the drive outside of windows? I've used some Hex editors to look at raw disk content, but there are WAY too many sectors to get through and the data is presented in very tiny ammounts. I'm looking for a high-level program that will quickly show me used vs. unused sectors.
Bump. Question is still unresolved.
I'd like to know the answer as well.
The wiki page suggests that trim will in fact work - but I'd like to be sure.
Bump. I'd also like to have confirmation of this.
I am interested as well.
Andreas
Back in late 2013 or early 2014 I did a bunch of testing on a system with a Crucial M550, Win7pro 64bit, and TrueCrypt 7.1a running FDE on the system boot drive. I did a manual TRIM after the initial encryption pass and ran some more tests to confirm that TRIM was happening from the OS (which didn't know the low level FDE was in place). My tests convinced me that TRIM was still happening so it was possible for an advanced adversary to determine which blocks were in use and which weren't but all the used blocks were encrypted. The way I proved to myself that TRIM was happening was that I could write data to a medium sized file, truncate (but not delete) the file, move the end of file back to the previous point (without writing to the intervening blocks) and then re-read the blocks from which I then got random data. I because I never re-wrote the intervening blocks wear leveling should not have occurred for them. The random result was due to the "encrypted" ciphertext blocks contain all zeros (0x00) and the decryption then made the "decrypted" cleartext random gibberish.
Still, it would be nice to get confirmation that Veracrypt does the expected thing for those of us willing too expose how much of the disc is in use.