CFS v TCFS v SFS v GBDE v ?

Mon Feb 17 11:46:18 PST 2003

This is interesting; thanks, David.

Further research suggests that TCFS has been experimentally ported to OpenBSD and NetBSD but
not formally ported to FreeBSD; my operating system of choice.

TCFS appears to be a bastard child of CFS, dependent upon NFS and intended to permit sharing
of encrypted contents across insecure networks. It appears to rely upon an interesting
mechanism for access to the contents, where each client only has a portion of the key required
to unencrypt the data and access to all (or a majority) of these clients - essentially, their
consensus - is required before the data can be decrypted. The threshhold can be adjusted.

Regrettably, TCFS is still heavily reliant upon the loopback mechanism used by NFS; and my gut
feeling is that while consensus mechanisms are intellectually interesting, that from an
administrative point of view they represent a snake's pit of dependencies, like NFS, but with
the clients voting on every disk operation. Also, much of this functionality is provided, at a
lower level, by VPNs and IPSEC, rendering the need for securing shared data, explicitly at the
filesystem level, less urgent.

However, the need for a locally encrypted storage mechanism that does not mandate managing
pass phrases for each separate file is still visible.

David, your description of GBDE provoked me to wonder if GBDE was derived from ccd (with which
I have not yet worked). I seem to recall that ccd conceptually paralleled a product with which
I have worked - SunOS metadevices - where one can create partitions on a disk ... associate
them with pseudo device drivers that treated them as mirrored, or concatenated, devices ...
associate -these- pseudo device drivers with other, next-level pseudo device drivers, that
concatenated the mirrors, or mirrored the concatenation ... until the desired level of
functionality was achieved.

I wonder because it occurs to me that this code base would be an excellent place to start if
one were to wish to develop such a thing as an encrypted filesystem, without needing it to
depend upon NFS or a loopback device.

As for CFS, it occured to me that it could be pushed into an NFS role; but I'm still thinking
about weaknesses (outside of the usual RPC stuff).

Thanks,

-- richard

David Wolfskill wrote:

> >Date: Mon, 17 Feb 2003 07:51:46 -0800
> >From: richard childers / kg6hac <fscked at pacbell.net>
>
> >I'm evaluating filesystems which provide encryption under
> >FreeBSD.
>
> >The following acronyms means the following things:
>
> >CFS: Cryptographic File System
> >TCFS: Translucent CFS
> >SFS: Secure File System
>
> >...
>
> >Have I missed any other encrypting filesystems?
>
> GBDE -- available only in FreeBSD-5.x (which recently acquired
> "-RELEASE" status for the first time, but you don't want to use 5.0 for
> GBDE, as I recall).
>
> The acronym stands for "GEOM-based disk encryption".
>
> It is not, strictly speaking, an "encrypting filesystem," as this is
> below the level of "filesystem":  you can put any sort of file system on
> it that you could on a "raw" disk.  Thus, the idea is that you can set
> up a (piece of a) disk en encrypted via GDBE, then create a filesystem
> of your choice on it; absent the key(s) to unlock the disk in question,
> even the type of filesystem that is on it should be non-trivial to
> determine.
>
> For more information:
>
> d144(5.0-C)[1] apropos gbde
> gbde(4)                  - Geom Based Disk Encryption
> gbde(8)                  - operation and management utility for Geom Based Disk Encryption
> d144(5.0-C)[2]
>
> I haven't done anything with it (yet), but Lucky Green came to a recent
> BAFUG meeting (January's) and mentioned it with a fair degree of
> enthusiasm (or so I perceived; I could be wrong).
>
> Cheers,
> david       (links to my resume at http://www.catwhisker.org/~david)
> --
> David H. Wolfskill                              david at catwhisker.org
> WARNING: Use of Microsoft products may be hazardous to your system's integrity.