From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:40:29 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 1054916A40D for ; Sat, 23 Feb 2008 19:40:29 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-out-05.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 873FF13C459 for ; Sat, 23 Feb 2008 19:40:28 +0000 (UTC) (envelope-from dds@FreeBSD.org) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.13.8/8.13.8) with ESMTP id m1NJOSZT019571; Sat, 23 Feb 2008 21:24:28 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id m1NJORs0004001; Sat, 23 Feb 2008 21:24:27 +0200 Received: from [192.168.136.22] ([62.1.173.114]) by MX-IN-05.forthnet.gr (8.14.2/8.14.2) with ESMTP id m1NJOPfw015723; Sat, 23 Feb 2008 21:24:27 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=dds@FreeBSD.org; spf=permerror Authentication-Results: MX-IN-05.forthnet.gr header.from=dds@FreeBSD.org; sender-id=permerror Message-ID: <47C072E9.9020900@FreeBSD.org> Date: Sat, 23 Feb 2008 21:24:25 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 MIME-Version: 1.0 To: Pieter de Boer References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> In-Reply-To: <47C068B5.2090000@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org, Atom Smasher 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: Sat, 23 Feb 2008 19:40:29 -0000 Pieter de Boer wrote: > 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? >> >> > The attack you're referencing is carried out by cold rebooting a system. > Simply put: pull power cord, insert power cord. The volumes are never > detached, as the shutdown sequence is never run. > > This attack has to be defended against in hardware; it exploits a > 'feature' of modern day RAM chips, which can not be controlled by > software. Anything that is in RAM when the attack is carried out, will > be compromised. As encrypted volumes simply require keys to be in memory > to be able to use the volumes, the encryption software is vulnerable to > this attack. I see no reason why GELI/GBDE wouldn't be affected. > > A possible counter-measure would be to add wiping features to the RAM > modules themselves. When power is lost, the memory could wipe itself. > Still not perfect, but would certainly help. > There are (at least) two attack methods. One is indeed based on memory chips that retain their data after a shutdown, and software can't easily protect against this attack. The only way I can think would be to reserve a processor register for storing the encryption key. However, a second attack method is based on rebooting a hibernated machine with a different operating system and retrieving the encryption keys from the hybernation dump. One can protect against this attack by having the hybernation sequence unmount the encrypted filesystems and wipe out the keys from memory. Diomidis Spinellis - http://www.spinellis.gr