From owner-freebsd-security@FreeBSD.ORG Sun May 18 12:30:18 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4CF106567A for ; Sun, 18 May 2008 12:30:18 +0000 (UTC) (envelope-from robert.woolley@rwoolley.com) Received: from turtle-out.mxes.net (turtle-out.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7498FC25 for ; Sun, 18 May 2008 12:30:18 +0000 (UTC) (envelope-from robert.woolley@rwoolley.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by turtle-in.mxes.net (Postfix) with ESMTP id 036AD163F59 for ; Sun, 18 May 2008 08:18:51 -0400 (EDT) Received: from gumby.homeunix.com. (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 456F423E3F6; Sun, 18 May 2008 08:18:49 -0400 (EDT) Date: Sun, 18 May 2008 13:18:46 +0100 From: Robert Woolley To: freebsd-security@freebsd.org Message-ID: <20080518131846.375f85aa@gumby.homeunix.com.> In-Reply-To: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> References: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 18 May 2008 12:31:52 +0000 Cc: abi@e-arroyo.net Subject: Re: Vulnerability with compromised geli credentials? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 12:30:18 -0000 On Sat, 17 May 2008 17:41:13 -0700 (PDT) "Abiron Arroyo" wrote: > > I'm not really a developer, but was considering if there is a key > vulnerability in geli given that when you change a key there isn't a > disk update. > > Consider the scenario where a new file system is created and populated > with some files. At a later time the original key is changed because > someone has gained access to the key and passphrase. A new key is > generated and attached, but none of the files are modified. > The data is encrypted with a random master-key that's generated during the init stage. That key is itself encrypted with a user-key generated from the passphrase and keyfile, and the encrypted masterkey is stored on the disk. The master-key itself is never changed; if the new files were encrypted with a different key you wouldn't be able to read the old ones.