Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |