DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS - SSD trim
Date: Sat, 24 Apr 2010 17:59:15 +0200	[thread overview]
Message-ID: <20100424155915.GC23598@tansi.org> (raw)
In-Reply-To: <20100423225918.GD8023@linux-m68k.org>

On Sat, Apr 24, 2010 at 12:59:18AM +0200, Richard Zidlicky wrote:
> On Fri, Apr 23, 2010 at 10:45:34PM +0200, Milan Broz wrote:
> 
> > I asked how TRIM (and SCSI discard) is handled and it seems that most of drives zeroes
> > trimmed blocks (or the function is internal to drive - so undefined, we must expect the worst case).
> > 
> > So it is clear that an attacker can recognize which block was trimmed (reading
> > zeroed blocks instead of "random" data). If there is some internal drive data
> > related to TRIM available, it can be even worse.
> 
> it can be even much worse. The most evil case is a specially crafted device manufactured
> by a mighty agency which will record every single read/write/trim command. A few weeks ago
> it was on the news here that most copiers have builtin hard discs and make copies of what
> people are copying.. so who knows what is in our ordinary hard discs today.

Only as temporary storage. Better copiers do a secure erase after
the copy as well, but not all do. It is something copiers used
for secret material can get certified for.
 
> The second most evil - and very realistic scenario is that any drive can
> have a log storing trim states/operations. If its an SSD device that log
> could be *very* huge if we are unlucky.  Although I am not an expert on
> this devices I would think it is the obvious way to do it. All the
> information about trimmed blocks must be stored somewhere and in order to
> keep the "wear" low its likely to be log-structured, not a simple bitmask. 
> There is not an official way to retrieve this backlog but there may be
> device specific undocumented proprietary ways to do it or someone might
> open the chip.
>
> But there sure is no way to guarantee that any information that is ever
> entrusted to a blackbox device might not resurface again.

That is way you use encryoption on top. However, it is higly unlikely
current HDDs/SSDs store a lot of information of this type. The storage
space is just not there.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

  reply	other threads:[~2010-04-24 15:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 22:48 [dm-crypt] LUKS - SSD trim Felix Blanke
2010-04-21 23:00 ` Milan Broz
2010-04-21 23:03   ` Felix Blanke
2010-04-22  2:17     ` Arno Wagner
2010-04-22  8:42       ` mark
2010-04-22  9:37         ` Milan Broz
2010-04-22 20:12         ` Felix Blanke
2010-04-22 22:20           ` Richard Zidlicky
2010-04-22 22:22   ` Richard Zidlicky
2010-04-23  8:49     ` Milan Broz
2010-04-23 10:20       ` Mikko Rauhala
2010-04-23 11:13       ` Richard Zidlicky
2010-04-23 11:46         ` Milan Broz
2010-04-23 20:09           ` Richard Zidlicky
2010-04-23 20:45             ` Milan Broz
2010-04-23 22:59               ` Richard Zidlicky
2010-04-24 15:59                 ` Arno Wagner [this message]
2010-04-24 16:44                   ` Richard Zidlicky
2010-04-24 17:01                     ` Arno Wagner
2010-04-22  6:17 ` Heinz Diehl
2010-05-14  7:35 ` JG
  -- strict thread matches above, loose matches on Subject: below --
2010-05-27 13:14 Christoph Anton Mitterer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100424155915.GC23598@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox