Date: Tue, 01 Mar 2005 20:14:47 -0500 From: Roland Dowdeswell <elric@imrryr.org> To: "Steven M. Bellovin" <smb@cs.columbia.edu> Cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch Message-ID: <20050302011447.CF7333700F@arioch.imrryr.org> In-Reply-To: Your message of "Tue, 01 Mar 2005 17:15:11 EST." <20050301221511.3423C3C023E@berkshire.machshav.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050302011447.CF7333700F>