[RFC] Encrypting file system

[RFC] Encrypting file system

[V Bhanu Chandra]

Hi,

I am thinking of designing and implementing a new native encrypting
file system for the linux kernel as a part of a student / research
project. Unlike dm-crypt/loop-AES/cryptoloop, I plan to target
slightly more ambitious user specifications such as: per-file random
secret encryption keys which are in-turn encrypted using the public
keys of all users having access to that filesystem object (a copy
each), and these "tokens" stored along with the file as meta-data (in
an extended attribute, for example).

I've already come up with an initial conceptualization / design for
this and have just begun with the implementation.

Any comments / guidance / suggestions are most welcome and solicitated.

It would be helpful if someone has implemented (or is working on) a
patch for the kernel that implements RSA in the CryptoAPI, else I
might have to resort to have a user-space service for key management
tasks.

Warm regards,
Bhanu

--
V Bhanu Chandra,
Undergraduate Student,
Department of Computer Science & Engg,
IIT Kanpur, India

Re: [RFC] Encrypting file system

[Mario 'BitKoenig' Holbe]

V Bhanu Chandra <vbhanu.lkml@gmail.com> wrote:
> I am thinking of designing and implementing a new native encrypting
> file system for the linux kernel as a part of a student / research
> project. Unlike dm-crypt/loop-AES/cryptoloop, I plan to target
> slightly more ambitious user specifications such as: per-file random
> secret encryption keys which are in-turn encrypted using the public
> keys of all users having access to that filesystem object (a copy
...
> Any comments / guidance / suggestions are most welcome and solicitated.

Since you are talking about an encrypting filesystems but only
referencing encrypting block devices... Have you had a look at encfs
and/or StegFS already?
At least one of the encrypting block devices you mentioned (I don't
remember which one) already has the ability to have multiple keys.


regards
   Mario
-- 
I have great faith in fools; self-confidence my friends call it.
                                              -- Edgar Allan Poe

Re: [RFC] Encrypting file system

[Eduard Bloch]

#include <hallo.h>
* Mario 'BitKoenig' Holbe [Mon, Mar 06 2006, 01:17:53PM]:
> V Bhanu Chandra <vbhanu.lkml@gmail.com> wrote:
> > I am thinking of designing and implementing a new native encrypting
> > file system for the linux kernel as a part of a student / research
> > project. Unlike dm-crypt/loop-AES/cryptoloop, I plan to target
> > slightly more ambitious user specifications such as: per-file random
> > secret encryption keys which are in-turn encrypted using the public
> > keys of all users having access to that filesystem object (a copy
> ...
> > Any comments / guidance / suggestions are most welcome and solicitated.
> 
> Since you are talking about an encrypting filesystems but only
> referencing encrypting block devices... Have you had a look at encfs
> and/or StegFS already?
> At least one of the encrypting block devices you mentioned (I don't
> remember which one) already has the ability to have multiple keys.

IIRC encfs does something like this (global key protected with pass
phrase and optional per-file IVs). And there is a new development:
http://ecryptfs.sourceforge.net/

Eduard.

-- 
Fast jede Frau ist schön, wenn sie Charme hat. Fast jede Frau hat
Charme, wenn sie Scham hat.
		-- Sigmund Graff

Re: [RFC] Encrypting file system

[Michael Halcrow]

On Mon, Mar 06, 2006 at 04:01:33PM +0530, V Bhanu Chandra wrote:
> I am thinking of designing and implementing a new native encrypting
> file system for the linux kernel as a part of a student / research
> project. Unlike dm-crypt/loop-AES/cryptoloop, I plan to target
> slightly more ambitious user specifications such as: per-file random
> secret encryption keys which are in-turn encrypted using the public
> keys of all users having access to that filesystem object (a copy
> each), and these "tokens" stored along with the file as meta-data
> (in an extended attribute, for example).

You have just described exactly what I presented at OLS 2004 and
2005. The paper is available in the symposium proceedings. Another
post on this thread pointed to the eCryptfs web site:

http://ecryptfs.sourceforge.net/

A version (0.1) with mount-wide passphrase support (with a random
session key per file) has been fully implemented and is available for
immediate use. If you are running kernel version 2.6.15, you can build
eCryptfs as a stand-alone module. There is a preliminary design
document under development that is available from the web site too. It
covers passphrase-only functionality for version 0.1, and I am in the
process of working on a design document for version 0.2, which will
include per-file public key support. In version 0.3, I plan to
implement more advanced key management and policy support.

> It would be helpful if someone has implemented (or is working on) a
> patch for the kernel that implements RSA in the CryptoAPI, else I
> might have to resort to have a user-space service for key management
> tasks.

For eCryptfs, I have decided that the public key operations be best
routed to userspace code due to their high computational overhead and
the need for additional operations that are necessary to make public
key meaningful from a security perspective, such as certificate
processing, CRL's, and so forth.

Thanks,
Mike Halcrow
eCryptfs Lead Developer

Re: AMD64 X2 lost ticks on PM timer

[Timo Schroeter]

Hi,

I have the same problem with my Tyan K8E Board. I've connected 2 WD raptor
to the onboard SATA ports (nForce 4, RAID0 md). I noticed that my server
hung up this night, after reboot and checking the logfiles I found the same
messages:

time.c: Lost 141 timer tick(s)! rip poll_idle+0x14/0x19)
time.c: Lost 127 timer tick(s)! rip poll_idle+0xa/0x19)
time.c: Lost 92 timer tick(s)! rip poll_idle+0x14/0x19)
time.c: Lost 64 timer tick(s)! rip poll_idle+0xa/0x19)

I dont use the onboard nFORCE4 NIC but the BROADCOM one. 

I ran ./trtc with the following results:

1141680789:835638: rtc 256 int 0 0 (=0)
1141680790:104663: rtc 464 int 269 0 (=269)
1141680790:604729: rtc 448 int 501 0 (=501)
1141680791:104795: rtc 464 int 500 0 (=500)
1141680791:604862: rtc 448 int 500 0 (=500)
1141680792:104927: rtc 464 int 500 0 (=500)
1141680792:604994: rtc 448 int 500 0 (=500)
1141680793:105060: rtc 464 int 500 0 (=500)
1141680793:605126: rtc 448 int 500 0 (=500)
1141680794:105192: rtc 464 int 501 0 (=501)
1141680794:605259: rtc 448 int 500 0 (=500)
1141680795:105326: rtc 464 int 500 0 (=500)
1141680795:605392: rtc 448 int 500 0 (=500)
1141680796:105458: rtc 464 int 500 0 (=500)
1141680796:605525: rtc 448 int 500 0 (=500)
1141680797:105592: rtc 464 int 500 0 (=500)
1141680797:605658: rtc 448 int 501 0 (=501)
1141680798:105725: rtc 464 int 500 0 (=500)

I wonder if my server was frozen because of this error. If there will be no
fix soon, I think ist better to get a PCIexpress SATA2 card :(

Regards,

Timo Schroeter