Idea: Encryption plugin architecture for file-systems

Hello,

Lot of people would like to know their data in secure place, and the frequent usage of compression softwares could be time-consuming and boring sometime.

Idea:
extend the current file-system with an optional plug-in system, which allows for file-system level encryption instead of file-level. This could be used transparently for applications or even for file-system drivers. This doesn't mean an encrypted file-system, but a transparent encryption of a media instead.

Advantages:
#1: optional security level for every data, without user interaction. #2: if this idea is used e.g. for portable media (like cdrom), your backup could be in safe also.
#3: (almost;)) everybody could create own security plugin for their data, and not have to trust on the designers of a secure file systems.

I suspect that this idea may appeared in the past:(, but I haven't heard about it;).

So, what do you think about this? Is Linux kernel enough flexible to do this? What changes are necessary to do such a thing? Is there any other way, to have own security for file-systems or portable medias? Is this implementation could be used in the US?

Best regards,
Tamas Nagy

Have you tried:

man losetup

losetup /dev/loop0 /dev/hdxx -e DES
mke2fs /dev/loop0
mount /dev/loop0 /mnt/

Alistair Riddell - BOFH
IT Support Department, George Watson's College, Edinburgh
Tel: +44 131 447 7931 Ext 176       Fax: +44 131 452 8594
Microsoft - because god hates us

ftp://www.kerneli.org/pub/linux/kerneli/

For idea encryption, you just use
losetup -e idea /dev/loop0 /filesystem
Password: whatever

mke2fs /dev/loop0
mount /dev/loop0

Tamas,
you may want to read this:

http://encryptionhowto.sourceforge.net/Encryption-HOWTO-4.html

the international kernel patch (www.kerneli.org) has had this
implemented for some time. There is lot more info on crypto in Linux at:

http://encryptionhowto.sourceforge.net/

I don't think it's that involved but you can certainly apply a cipher to a mounted partition.

You can use it in the states but you cannot develop for it within the states - well, the regulations changes but I am not sure if the kerneli guys will trust that... that's a totally different debate in itself.

Bart.

	WebSig: http://www.jukie.net/~bart/sig/

That's is one of the things the loop device offers. For better encryption than XOR you need the patches from kerneli.org.

(Remember the problems whith crypto code in the US is mainly with exporting it neither importing or using it.)

hash-bang-slash-bin-slash-bash

I think he wants to avoid the *!!SEVERE!!* performance problems in loopback crypto. A crypto plugin directly to filesystems would certainly avoid most of it.

-Dan

I'm currently in the situation where I need to mount an encrypted file system over NFS (on a slow link), and the performance considerations pretty much rule out the loop approach. (Currently I'm using CFS because I found no other choice[1], but it is another loop approach - stacking one NFS on top of another NFS - and that makes it painfully slow too.)

The theoretically best solution is TCFS (www.tcfs.it), which builds encryption into the NFS client alone, but it is not available for anything newer than Linux 2.2.16.

Olaf

[1] Esp. if the requirement is that it can survive a kernel upgrade.

No, you don't. The standard kernel loop device supports loading of external crypto filters just fine; no patching at all required.

-Andi

you're right, by using...

int loop_register_transfer(struct loop_func_table *funcs); int loop_unregister_transfer(int number);

...one can register new transfer functions, but they rely on 'magic numbers' for identifying the given crypto cipher, some of which are defined in linux/loop.h; with the highest magic number being MAX_LO_CRYPT (so patching is required nevertheless, if you want to have more than 20 ciphers by that scheme...)

#define LO_CRYPT_NONE     0
#define LO_CRYPT_XOR      1
#define LO_CRYPT_DES      2
#define LO_CRYPT_FISH2    3    /* Brand new Twofish encryption */
#define LO_CRYPT_BLOW     4
#define LO_CRYPT_CAST128  5
#define LO_CRYPT_IDEA     6
#define LO_CRYPT_DUMMY    9

#define LO_CRYPT_SKIPJACK 10
#define MAX_LO_CRYPT 20

well.... the only thing I don't really like about this is, that its a static allocation of cipher id's, instead of a dynamic lookup by name and I'm not sure how well module autoloading works by this scheme... (the international crypto api offers string lookup for ciphers, and registers itself as one of those numeric cipher ids as far as loop device usage is concerned)

btw, there's still an issue with with the IV value being calculated on varying blocksizes, which I pointed out some time ago (instead of being calculated on 512 byte sectors, which I assume to be the smallest possible blocksize settable on a device)

greetings,

Herbert Valerio Riedel      /     Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142

But it is a definite performance killer. A direct plugin to filesystems would be far more efficient.

-Dan

Not sure what you have in mind exactly, but there are related projects:
- the crypto modules in the international linux kernel (see http://encryptionhowto.sourceforge.net/Encryption-HOWTO.html)
- Erik Zadok's FIST (http://www.cs.columbia.edu/~ezk/research/fist/)
- the Transparent Cryptographic File System (http://www.tcfs.it/)
- Stefan Ludwig's Fairly Secure File System
(http://osg.informatik.tu-chemnitz.de/publikat/da/00/Ludwig00.pdf,
diploma thesis, in German)
- Allan Latham's practical privacy disc (device) driver
(http://linux01.gwdg.de/~alatham/ppdd.html)
- Matt Blaze's CFS seems to be discontinued/unsupported
(http://koeln.ccc.de/~drt/crypto/cfs-linux-HOWTO.txt)
Maybe you clarify what exactly you want to achieve/improve compared to the existing projects.

Stefan J.

Talk about syncronicity... I had just last week asked about the pro's and con's on this on the crypto list and have heard nothing at all back. So I'll drop the body of that message in here:

--
I've got a crypto loopback running directly on a /dev/md0 partition and then the file system on top of that. I'm interested in what the feelings of others are on the trade offs of doing it this way.

Is there something to be gained by adding a file system layer between the /dev/md0 and the loopback file as far as error recovery is concerned?

Do I actually gain performance (as I am guessing currently that I do) by eliminating one layer?

It's just a plaything right now, but I'd be interested in some feedback on the wisdom of it before I actually use this on something important. So just to reiterated:

fs
fs c. loopback
c. loopback vs fs
raid1 raid1
disk disk disk disk

where fs = ext2 until this evening when I replace it with reiserfs.
--

And update by saying I've got reiserfs working on top of it with no problems. But I'm still just that wee bit nervous about the approach even though it works.

What happens if I get one bad disk sector in a partition? What is the difference in data loss between encrypting on the bare partition versus having say, a reiserfs under you?

(Obviously RAID doesn't save you. It will just merrily reproduce the bad sector on the mirror disk)

------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

why not port one of the twenty or thirty preexisting tools that let you mount a filesystem from an encrypted file instead of making a generic layer? That way you could have inter-os portability. The steganographic ones make really impressive claims.

Does linux have a truly generic plug-in file system module yet, or are people still hacking around fake nfs servers?

                      David Nicol 816.235.1187 [email protected]
                                    "Described as awesome by users"

I'm doing an 18GB raid file system. The standard loopback is working fine. What I am unsure of is the bobustness against lost blocks when running "on the metal" vs interposing another file system layer.

I suspect the answer is that each block is individually encrypted, so that the worst case data loss is the same; that an ext2 on top of an encrypted partition would be no worse off than the same file system without the interposed layer. Both would find a bad block and do their best.

But my knowledge of how the loopbacks are structured is not good enough for me to say this with confidence. That's why I'm asking here: in hopes that someone who really does know can say something about the worst case data loses.

------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------