Date: Wed, 25 Oct 2006 22:42:24 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-fs@freebsd.org, Robert Krten <root@parse.com> Subject: Re: Naive question about encrypted disks Message-ID: <20061025223246.G33725@fledge.watson.org> In-Reply-To: <453FBCDF.5050807@samsco.org> References: <200610251642.k9PGgr4t054536@amd64.ott.parse.com> <20061025180112.P33725@fledge.watson.org> <453FBCDF.5050807@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Oct 2006, Scott Long wrote: >> Deriving the key when you have examples of plaintext and ciphertext for >> that plaintext is known as a "known-plaintext attack". Resistence to >> known-plaintext attacks is one of the most important properties required of >> modern crypto algorithms. Other examples of cases where resistance to >> known-plaintext attacks is critical include: >> >> - IPSEC, where it's often the case that a potential attacker can trigger >> known >> plaintext to appear in the plaintext, and also through a packet sniffer >> gain >> access to the ciphertext, but is not permitted to know the secret key. >> >> - SSL web servers, where a customer of an ISP may be able to provide >> content >> delivered using SSL, and can gain access to the ciphertext, but should >> not >> be able to derive the key. >> >> There are attacks that reduce the computational cost of deriving keying >> materials against known crypto algorithms; however, those attacks typically >> do not signifcantly weaken the cipher. Where they do, we have a special >> term we can use to describe the algorithm: "broken". >> >> Many crypto protocols (that is to say, conventions involving the use of >> crypto) include "salt" or "initial vectors" (IVs) to limit the >> effectiveness of dictionary attacks and known-plaintext attacks by causing >> the same plaintext to be encrypted differently each time it is encrypted. >> These are typically pseudo-random values, or in the case of chained crypto >> modes, earlier data in the ciphertext or cleartext, or in the case of >> counter mode, a incrementing counter. > > So, if you know that multiple superblock copies are going to be written at > predictable places on the disk, and you know that the these copies are > identical, unchanging, and have predictable contents, does that give you a > starting point for a known-plaintext attack? I believe that is the question > here. Even if the block granularity of GBDE ensures that the superblocks > will be encrypted with other less-predictable data, could you still predict > that the outter cylinder groups of the disk might be unused, and therefore > have lots of predictable data on them? A detailed description of the gbde design can be found here: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf While I don't know too much about the details, the paper indicates that there are a few elements of the gbde design to counter the known plaintext nature of the superblocks, cylinder groups, etc: (1) Random sector relocation. Without the keying material necessary to unlock the master key sector, you can't trivially locate the block in question. A portion of the master key is used to cryptographically generate the actual physical sector storage location for the logical sector. (2) A generated per-sector key, stored in key storage sectors, is used to encrypt each sector. So while the IV paramater to the crypto algorithm is zero, the keying material is different, so the same superblock contents will be encrypted to different ciphertet. The first portion addresses an initial concern about locating sectors believed to have predictable content, and the second portion addresses the encryption of the same data to the same plaintext. In the administrative directions in the paper, it's also recommended that the disk surface be completely randomized before beginning so that there isn't a usefully identifiable difference between "never written" and "in use or deleted" blocks when initialized on a disk with arbitrary (but possibly non-random) contents. A quick look at the gbde(8) admin tool suggests that it does not randomize disk contents, but I've not read closely. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061025223246.G33725>