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
next prev parent 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