[mike@halcrow.us: gnupgfs]

[Michael Halcrow]

I tried sending this a while back, but it appears that it went into
the bit bucket...

----- Forwarded message from Michael Halcrow <mike at halcrow.us> -----

From: Michael Halcrow <mike at halcrow.us>
To: gnupg-devel at gnupg.org
Subject: gnupgfs
Reply-To: Michael Halcrow <mike at halcrow.us>

Okay, so it's called cryptfs at the moment, but I would like to
implement something that is gpg-compatible in my encrypting
filesystem.  At the moment, crypto context is stored in the extended
attribute set for each file, and the kernel crypto API is used to set
up the context accordingly.  David Howells recently submitted a
well-featured keyring to LKML.  I presented a working demo of cryptfs
at the Ottawa Linux Symposium last week, and it was really well
received.  People seem to want this kind of thing.

I was planning on implementing userspace tools to allow the individual
files to be accessable by those who may not be running cryptfs on
their platforms.  It makes a lot of sense to make the files
decryptable via GnuPG.  Some features will be lost in the process
(i.e., extent-based integrity verification), but that's better than
not being able to access the contents of the file at all.

My paper is here:

http://halcrow.us/~mhalcrow/ols2004.pdf

The basic idea is that the user's private key gets passed into the
kernel keyring via a PAM module at the time that the user logs in (his
authentication token, the login password, is used to get the private
key from ~/.gnupg/secring.gpg).  This is possibly combined with a
secret key extracted from a TPM (binding files to hardware devices).
cryptfs is mounted over the root/home/whatever.  When a file is
opened, cryptfs makes its own inode and dentry, and interposes them
with those of the underlying filesystem.  If the user.encrypted
Extended Attribute is set, then the crypto context is initialized for
the file.  Else, address_space ops for readpage/writepage/etc. are
assigned to those of the underlying filesystem.  Alternatively, one
check could include whether or not the GnuPG header is present, and if
so, follow policy for that file (sometimes you will want cryptfs to
just leave the file alone).

The end result is that user applications can transparently read and
write .gpg files, as long as the UID has the proper private key
associated with it in the kernel keyring, which happens when the user
logs in normally.  No more worrying about encrypting and decrypting
files manually while working with them.

Policy is a big issue here.  Default crypto contexts can, for example,
be attached to directories or filesystems via .cryptfsrc files or what
not ("Every file written to this location must be encrypted with Alice
and Bob's public keys"; makes secure file sharing via a USB pen drive
somewhat easier).  Also, what mutt gets when it opens a file is an
issue.  Will mutt be sending the file outside of the local security
domain as an email attachment?  If so, it should get the encrypted
data.  Is it .mail_aliases?  It probably needs the decrypted data.
You get the idea.

I also have a userspace daemon that can be queried for
keys/passwords/decisions in cases where these things may be needed.

So I need to put a subset of GnuPG into my filesystem to support this.
I have made a first pass over RFC 2440, but it would be helpful if I
could work with one or more GnuPG developers in doing the job right
(assuming it can be done at all; I basically need to be able to jump
to an offset in the file and start block encryption/decryption via
kernel crypto API scatterlists).

Thanks,
Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D



----- End forwarded message -----

-- 
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

A computer without a Microsoft operating system is like a dog        
without bricks tied to its head.