All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.