From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 01:15:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 577C616A4CE for ; Wed, 2 Mar 2005 01:15:05 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id B95FF43D2D for ; Wed, 2 Mar 2005 01:15:04 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id CF7333700F; Tue, 1 Mar 2005 20:14:47 -0500 (EST) To: "Steven M. Bellovin" In-reply-to: Your message of "Tue, 01 Mar 2005 17:15:11 EST." <20050301221511.3423C3C023E@berkshire.machshav.com> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Tue, 01 Mar 2005 20:14:47 -0500 From: Roland Dowdeswell Message-Id: <20050302011447.CF7333700F@arioch.imrryr.org> cc: ALeine cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 01:15:05 -0000 On 1109715311 seconds since the Beginning of the UNIX epoch "Steven M. Bellovin" wrote: > >It's worth noting that there is a very real threat not addressed here: >detecting unauthorized changes to an encrypted disk. For a very >elegant solution, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings >/papers/storageint.pdf I thought about this a little when I was writing CGD and decided that since it would involve changing the block size or updating multiple blocks when one block was modified that it would be handled much better at the file system layer than at the disk layer. E.g. right now LFS uses a checksum to determine if a segment write has fully completed upon recovery from a crash. It would be easy to modify that checksum into an HMAC. That would provide integrity protection almost for free. If we did it at the disk level, then we would be in the game of trying to make 2 disk writes appear atomic which would be a serious performance problem. On the other hand Thor Lancelot Simon made an interesting suggestion recently, which was one could reformat the underlying disk to have 522 byte blocks but have CGD present 512 byte blocks to the layers above it and still maintain the appropriate atomicity while gaining a 160 bit HMAC for each block. I think that the integrity checking has a more limited threat model, namely only removable media (for NetBSD, at least). If someone is able to steal my laptop and return it, they could just bug the keyboard much more quickly than figure out how to change my encrypted partitions in a non-obvious way. Or they could circumvent the boot blocks, reflash the BIOS, etc. etc. So, I think that this only matters for media which is more likely to pass out of my direct control than my laptop---or as in the article NAS/SAN architectures, where the storage is not nec. coresident with the computer. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/