Encrypting on SSD

ajay11

Posts: 20   +0
Hello,
Veracrypt and Truecrypt user guides discuss valid concerns that an encrypted file container could easily be compromised if stored on an SSD (or any drive using wear leveling, TRIM or the like). If I understand the concerns correctly, the problem is caused mainly by copies of the volume header spread over many sectors.

Here is my questions. Is anybody aware of any sort of protection which is easy to implement - without going back to slow magnetic drives ?

(So far ;) I am not willing to carry my laptop wherever I go with a external HDD (magnetic drive) hanging down from a cable. Is there any other solution ?
Best
 
IMO, it's ludicrous to encrypt the whole storage device. Massive portions are just impersonal control structures without any user content. Equally absurd is to fuss with c:\Windows -- that's as common as all heck.

One might propose to protect c:\Users but that too is extremely conservative.

The precious stuff is in %USER%\AppData and %USER%\Documents
 
Totally agreed, I would not want to encrypt the whole drive either. But how would one solve the problem that automatic TRIM / wear leveling will spread the volume headers all over the SSD in smaller or larger pieces ?
 
Remember, our applications interact with the Filesystem, NOT sectors per se. In a totally defrag'd disk, all files are in one contiguous set of clusters. When free space is also defrag'd, even the volume headers are in groups, but not fragmented.

R/O files don't matter to the SSD but files you modify do -- and that includes System Updates, Registry files and the pagefile.sys. Even M$ recommends against using an SSD for the boot device, so you're headed up a hushing creek with a teaspoon for a paddle IMO.
 
I have come across one potential solution and I am looking for a critical comment. If one had to work with an SSD, and needed to encrypt part of it, ... and didn't want to risk that parts of the key (e.g. Truecrypt masterkey) becomes recoverable because of TRIM and wear leveling. So how about ...
create an outer encrypted, container, never change it's password (see Truecrypt UM why), and put the required, critical container inside.
At first glance this doesn't seem to solve the problem, but I am not so sure. Bits of the inner volume header still get spread around ... but within encrypted sectors only, even if the outer password got compromised ?
 
Sectors per se don't not get attacked. Someone after your data will go thru the name->allocation-map. Attempting something like
Code:
Object
{ 1st enternal obj;
   2nd enternal obj;
...
}
is meaningless AND you would need to be able to do all that extra coding yourself.
 
Back