One way to do this would be to simply encrypt the files before placing them on the server. Actually, encryption on the server itself would probably be fine to, since files will be transferred via SSH anyway. However, if I were to do this, metadata (such as file and directory names) would not be encrypted.
Another option would be encrypting the entire file system. There are several ways of doing this, but in general the encrypted file system would be placed in a file or on a raw device using some kind of loopback driver. That would mean that the data itself would need to be backed up the block level, either using tools like dumpfs or using snapshots (ZFS, LVM, etc). Since I would like to be able to use regular tools like tar to create backups, I don't consider encrypted file systems ideal for what I'd like to do with it. Since backup up a backup would not be that useful, this would only be an option for that is not stored anywhere else.
Since I don't expect performance to be a real issue, a userland file system would probably be fine. A big advantage would be that developing and testing something myself would not require root privileges and considerably lowers the chance of screwing up the server itself. FUSE looks like it might be a good choice.
FUSE was developed on Linux (requires some kernel support) and as far as I've seen there is support for running it on FreeBSD, NetBSD, OpenBSD and Mac OS X. There is also a OpenSolaris project for FUSE.
What I'm thinking about now is a FUSE file system, in which:
- file contents would be encrypted (probably AES) with the algorithm running in CBC mode
- files will optionally be compressed
- file and directory names would be stored as fixed-size identifier (not a hash of the actual name)
- the underlying file system could be of any type supported by the kernel
- the underlying storage would contain an encrypted index file which would contain the per-file encryption key, data to translate file/directory identifiers to their original name and a checksum (CRC32 or MD5 should be good enough, as it would only be used to quickly check for changes) of the original file before compression/encryption
This is somewhat similar to the way in which Apple stores music on an iPod. They move meta data to a proprietary 'database' to frustrate attempts at copying the music from an iPod to a computer. Perhaps the data is only obfuscated, but it might be encrypted with a key that's also stored in the firmware. Either way, I am sure there is software out there which has no problem extracting music from an iPod with the meta data intact.
