From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Sat, 24 Apr 2010 17:56:07 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTPA id 2DEB6212804A for ; Sat, 24 Apr 2010 17:56:07 +0200 (CEST) Date: Sat, 24 Apr 2010 17:59:15 +0200 From: Arno Wagner Message-ID: <20100424155915.GC23598@tansi.org> References: <20100422004842.5eb40c0a@gmail.com> <4BCF8371.60306@redhat.com> <20100422222227.GC15879@linux-m68k.org> <4BD15F13.3040604@redhat.com> <20100423111337.GA26121@linux-m68k.org> <4BD18899.7080700@redhat.com> <20100423200901.GA8023@linux-m68k.org> <4BD206EE.9070606@redhat.com> <20100423225918.GD8023@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423225918.GD8023@linux-m68k.org> Subject: Re: [dm-crypt] LUKS - SSD trim List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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