From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 24 17:33:31 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 550EF16A403 for ; Sun, 24 Feb 2008 17:33:31 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id F3AC313C45A for ; Sun, 24 Feb 2008 17:33:30 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from working (c-71-60-127-199.hsd1.pa.comcast.net [71.60.127.199]) (AUTH: LOGIN wmoran, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Sun, 24 Feb 2008 12:33:29 -0500 id 0005641F.47C1AA69.00013C3A Date: Sun, 24 Feb 2008 12:33:28 -0500 From: Bill Moran To: "Igor Mozolevsky" Message-Id: <20080224123328.a0a85d7c.wmoran@collaborativefusion.com> In-Reply-To: References: <47C06E1F.5020308@thedarkside.nl> <760775.85636.qm@web50306.mail.re2.yahoo.com> <20080223203316.GC38485@lor.one-eyed-alien.net> <20080224100924.c8e08776.wmoran@collaborativefusion.com> Organization: Collaborative Fusion Inc. X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org 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 17:33:31 -0000 "Igor Mozolevsky" wrote: > > On 24/02/2008, Bill Moran wrote: > > "Igor Mozolevsky" wrote: > > > > > > On 23/02/2008, Brooks Davis wrote: > > > > > > > > > > > You should actually read the paper. :) They successfully defeat both > > > > of these type of protections by using canned air to chill the ram and > > > > transplanting it into another machine. > > > > > > Easy to get around this attack - store the key on a usb > > > stick/cd/whatever and every time the OS needs to access the encrypted > > > date the key should be read, data decrypted, then key wiped from the > > > memory; or have the daemon erase the key from memory every T minutes > > > and re-acquire the key at next access attempt... > > > > > > This is only effective if the sensitive data is infrequently accessed. > > If the unit is asleep, then software isn't running and it's not possible > > to kick of a timer to clear the memory, so it doesn't even start to > > solve that problem. > > IMO the possibility of such attack is so remote that it doesn't really > warrant any special attention, it's just something that should be kept > in mind when writing "secure" crypto stuff... Then you're not using this to protect data of a particular sensitive nature, or you're being a fool. Fact is, data is "sensitive" to different degrees. It's also valuable to different degrees. If you're worried about your personal financial information on your laptop being stolen, then modern disk encryption is fine. But, if you've got a mobile device with the sensitive information from 1000s of people on it, the stakes are different. That device is liable to be the target of an attack specifically to get the _data_. You're correct in 90% of the cases, but there's still the 10% that some of us need to consider. The fact is that the attack is not difficult, and it's not a matter of whether or not someone _can_ bypass your disk encryption, it's more a matter of whether or not they actually care enough to bother, or whether the $$$ they can get for the stolen hardware alone will satisfy them. Each user/organization really needs to evaluate this information with regards to their own situation, but it's important to understand the details of the risk when making such a decision. -- Bill Moran Collaborative Fusion Inc. wmoran@collaborativefusion.com Phone: 412-422-3463x4023