Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] TrueCrypt with SSD



Unfortunately I don't have anything to contribute here. Basically all
disk I/O systems, encrypted or not write fixed length sectors. Since
most Linux I/O is buffered, there is not much of a performance hit. But,
the nature of SSD as discussed. There is certainly an individual file
encryption, but these don't encrypt swap. Additionally, if the user
loses the laptop without powering it off, a lot of stuff can be
recovered from RAM. essentially it all comes down to the behavior of the
user of the laptop. Even if you have full disk encryption, the behavior
of your boss could effectively make encryption useless. TrueCrypt also
does have some optimizations for SSD drives. I think that a lot of stuff
like TrueCrypt provides a very false sense of security. Personally, I
would opt for a self destruct where the laptop explodes if stolen :-)

On 08/15/2011 09:07 AM, Chris O'Connell wrote:
> Does anyone know of any other methods to securing the data on a solid state
> drive?  Any BIOS level or TPM integrated security?
>
> On Mon, Aug 15, 2011 at 8:45 AM, Chuck Anderson <cra at wpi.edu> wrote:
>
>> On Mon, Aug 15, 2011 at 07:45:26AM -0400, Edward Ned Harvey wrote:
>>> Incidentally, what *is* the problem with TrueCrypt anyway?  It seems to
>> me,
>>> a hard drive looks like a hard drive whether it's a HDD or SSD.  I would
>>> expect it to be fine.  Do they have any details anywhere, what is the
>>> problem?
>> Sure, an SSD looks the same as an HDD to the application running on
>> it.  But unlike HDDs, SSDs perform (in some cases much) worse and wear
>> out faster when they are full vs. when they still have empty unused
>> space.  So the ATA TRIM (and SCSI Discard) command was invented as a
>> way for the application (i.e. filesystem, RAID subsystem, LVM,
>> encryption subsystem, etc.) to tell the SSD which sectors are free/no
>> longer in use.  In a normal, unencrypted scenario, a disk starts out
>> mostly empty--the sectors start out zeroed and are only written to
>> when they are actually needed.  In contrast, encrypted disks are
>> always completely "full" or "untrimmed", because from the time they
>> are initially formatted and encrypted every sector is written to with
>> non-zero data because the empty encrypted sectors (i.e. the unused,
>> zeroed blocks of a filesystem living on top of the encrypted mapping)
>> appear random once they are encrypted onto the underlying physical
>> device.
>>
>> TrueCrypt and many other full disk encryption packages cannot tell the
>> drive which sectors are actually free (and hence maintain them as
>> zeroed sectors on the SSD) because they don't support TRIM.  Many of
>> the packages don't want to support TRIM because it would leak
>> information about the encrypted disk to a potential attacker.  That's
>> pretty much it in a nutshell.
>> _______________________________________________
>> Discuss mailing list
>> Discuss at blu.org
>> http://lists.blu.org/mailman/listinfo/discuss
>>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org