From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 24 06:58:51 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BABF16A403 for ; Sun, 24 Feb 2008 06:58:51 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: from web50310.mail.re2.yahoo.com (web50310.mail.re2.yahoo.com [206.190.38.243]) by mx1.freebsd.org (Postfix) with SMTP id 5579613C442 for ; Sun, 24 Feb 2008 06:58:51 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: (qmail 92462 invoked by uid 60001); 24 Feb 2008 06:58:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=jXhFq6KLBz9uJQ6vH6mg3iXqqRI3M6ZWaYmshzHv0Q7LtooX0d1lURSphncePvlKxQl9O+r+bePZM9vNW28lGesFz4aKptS7M7VUYmED96gm2KcL9zy95Q9wuhQzrPN9J2WnY8f7kibaoFNSjyVehJDgqyyJr2Gn9Tl6AXzz9U4=; X-YMail-OSG: hkm2SUYVM1lpXIerLpNnie6e6J8pF6nUgH.Z6SH4ITRVN5nBzFxi2GsS.BEiRefkCJY8DFmKxQNZGh8Mqtp_UI3YbGJ7pTBXqa0Dl2b7GYD5RZUz3fP4Ll9edYZ3nKJrcp8SijZXYp_GoQc9BsEZ3V7ygQ-- Received: from [210.215.149.194] by web50310.mail.re2.yahoo.com via HTTP; Sat, 23 Feb 2008 22:58:50 PST Date: Sat, 23 Feb 2008 22:58:50 -0800 (PST) From: Tim Clewlow To: hackers@freebsd.org In-Reply-To: <47C0AD9D.2070701@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <257786.91158.qm@web50310.mail.re2.yahoo.com> Cc: Subject: Re: Security Flaw in Popular Disk Encryption Technologies X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 06:58:51 -0000 --- Dimitry Andric wrote: > On 2008-02-23 02:08, Atom Smasher wrote: > > article below. does anyone know how this affects eli/geli? > > > > from the geli man page: "detach - Detach the given providers, which means > > remove the devfs entry and clear the keys from memory." does that mean > > that geli properly wipes keys from RAM when a laptop is turned off? > > This is a physical attack, and there's nothing you can do in software to > prevent it. Of course geli or other software can attempt to erase the > keys from RAM as soon as it's done using them, but it won't prevent > hijacking them beforehand. > > It's the same with all physical attacks: hardware sniffers, keyloggers, > TEMPEST, etc. You need physical (hardware) protection to secure > against these, not software. The cracking method relies on the ability to find the key in memory, so, if the key is obfuscated then this would mean the cracking method could no longer find the key even if it has access to memory. For example, create a series of random bytes of equal length to the key, lets call that the "obfuscator". And now xor that with the key, lets call that the "xord key". To use the enc/dec system an extra step would need to xor back to the original key. The idea is that real key is only created when needed for use, and then immediately overwritten after use. If the "obfuscator" and the "xord key" are stored in memory at unpredictable locations, ie dont just have them sitting next to each other, then this would make it much more difficult to _find_ the key as it would now involve identifying two groups of randomly located (in memory) bytes that are xor'd to create the real key. Yes, with sufficient reverse engineering it would be possible to find out where the "obfuscator" and "xord key" have been stored, but this would at least stop the relatively trivial search method being used in the paper. Just a thought, and yes, I have now actually read the paper. Tim. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ