# High Security Network Filesystem

## ManDay

I would like to know whether there exists a filesystem which is network-based (thus mounted by a client), fully encrypted (and only decrypted by the client) and allows to balance the need for security and performance by choosing "chunks" in which the data will be encrypted.

Therefore: For maximum security, all data will be encrypted as one big chunk on the server. If the client wants to see the filesystem or do anything with it, it will have to transfer the whole chunk and decrypt it.

For better performance files/data are encrypted in smaller groups/chunks and the mapping between filename/datum and encrypted chunk is kept in an encrypted file (or even unencrypted).

Thinking about it, I did not see any alternative for a reasonable encrypted network filesystem (meaning encrypted on the server and only the client being able to decrypt data). Is there another way to achieve this kind of security with a lot of data?

I assume any such filesystem would usually be FUSE on the client with some particular daemon on the server (while the encrypted files on the server reside on an arbitrary filesystem). Any other thoughts?

Edit: On yet another thought, it seems like the server could be running anything it want, most likely CIFS or something of that sort and the client would run a FUSE which will do the encryption. The server could actually be totally ignorant of this encryption. So it's just a question about the right FUSE? Does any such FUSE exist already?

----------

## olek

http://serverfault.com/a/197155

----------

## ManDay

 *olek wrote:*   

> http://serverfault.com/a/197155

 

What does that have to do with my question?

----------

## olek

It lists and compares all the combinations of network shared filesystems and available security layers there practically are right now?

edit:

If the link doesn't answer your question(s), than please be more specific. Do you want the data to be encrypted on the fs or block layer?

It's not fully clear what you mean by "chunks".

Does the server <-> client connection need to be encrypted?

Shall the server be able to read the data?

----------

## Ant P.

Truecrypt or equivalent over Dropbox.

----------

## lagalopex

luks over sshfs?   :Laughing: 

----------

## ManDay

 *olek wrote:*   

> Shall the server be able to read the data?

 

Which part of "only decrypted by the client" do you need clarified?

Not sure whether the other two replies are jokes.

----------

## lagalopex

 *ManDay wrote:*   

> Not sure whether the other two replies are jokes.

 

Mine was no joke... (though still a funny setup I think...)

(Secure, but you need a huge file, where you put the fs in... does not scale good with the size  :Wink:  )

Accourding to a short google: encfs over sshfs.

(Should scale better, as the files are encrypted seperatly.)

----------

## ManDay

Well, the point is that I'm exactly looking for what I described: A balance. Neither everything in one big encrypted file, nor all files encrypted individually. That's why I don't understand why you mention all those which exactly don't do that (EncFS is of the latter type, btw).

----------

## olek

 *ManDay wrote:*   

> 
> 
> Which part of "only decrypted by the client" do you need clarified?

 

For example which layer should only be decrypted by the client.

If your post wasn't that incoherent I wouldn't need to ask such a beaic question and just maybe that's the reason you get joke answers.

So you want some data encrypted in some way (fs layer like ecryptfs or block layer like dmcrypt) with only the client having a key for it. ok, name it requirement 1.

but:

 *Quote:*   

> 
> 
> and allows to balance the need for security and performance by choosing "chunks" in which the data will be encrypted.

 

now again, what are those "chunks" exactly?

further:

 *Quote:*   

> Therefore: For maximum security, all data will be encrypted as one big chunk on the server. If the client wants to see the filesystem or do anything with it, it will have to transfer the whole chunk and decrypt it.

 

Now there are a couple of questions:

- who or what decides when to "balance for security and performance"?

- what is the point of "maximum security" when you give it up every once in a while for performance?

further while keeping your requirement 1 in mind:

- who and how should know where to look for specific "chunks" for performance?

A method of encryption that lets you see which chunk of data holds what chunk of plain data would be one steaming pile of shit type of encryption. any reasonable encryption under these circumstances should not store parts of data in one continous place.

now you can conclude:

whoever wants to serve encrypted data in selective "chunks" needs to know where to find it. so:

- either you can trust the server and: let the server read the data and encrypt the connection to the client

- or you cant trust it and: you forget about the whole "balance for security and performance" which seems bonkers to begin with.

 *Quote:*   

> If the client wants to see the filesystem or do anything with it, it will have to transfer the whole chunk and decrypt it.

 

- now for how much data are you planning for? 

if you use any type of reasonable encryption you either transfer the whole bunch of data before you can decrypt it locally. then you do whatever you need to do and if you changed something, send the complete block of data back. good luck with that if you plan to store more than a couple of GB like that.

now there might be a third way that involves exposing a raw encrypted block or fs via a network accessible interface over 9p or something alike and communicate directly with it. but if you cant trust the server or the connection and you plan to store very important data on that device it would still have security implications as all your fs or block level actions are seen by an eavesdroper / the server.

encryption isn't magic. give us your threat model and requierements and be more specific if you need proper help.

----------

## szatox

 *Quote:*   

> I would like to know whether there exists a filesystem which is network-based (thus mounted by a client), fully encrypted (and only decrypted by the client) and allows to balance the need for security and performance by choosing "chunks" in which the data will be encrypted. 
> 
> 

 What if I told you you want none of those things?

I have a feeling what you actually want is remote, encrypted data store. It doesn't equal network-based filesystem with integrated encryption and variable chunk size.

What you might be interested in is a stack of different features:

Block-level remote access -> e.g. iSCSI

Block-level encryption -> e.g. LUKS

Filesystem -> e.g. ext4

Obviously in the example above you can replace any of those parts with other things providing you the same value. You could for example use FC SAN instead of iSCSI. If you had it, of course.

 *Quote:*   

> 
> 
> Therefore: For maximum security, all data will be encrypted as one big chunk on the server. If the client wants to see the filesystem or do anything with it, it will have to transfer the whole chunk and decrypt it. 

  For maximum security keep your PC in a strongbox. Unplugged.

Will chunks bigger than the key size be harder to brute-force? Or will they simply eat more of your CPU, while providing additional surface for more sophisticated attacks? Are you good enough with cryptolography and cryptology to determine the most secure size?

And talking about FUSE: beware! http://thumbs.dreamstime.com/z/human-hand-holding-bomb-burning-fuse-white-background-31667892.jpg  :Laughing: 

----------

## lagalopex

 *ManDay wrote:*   

> Well, the point is that I'm exactly looking for what I described: A balance. Neither everything in one big encrypted file, nor all files encrypted individually. That's why I don't understand why you mention all those which exactly don't do that (EncFS is of the latter type, btw).

 

Just to clarify: When using luks over sshfs you dont need to transfer the whole container. Only those parts read/written by luks are transfered.

(The container does not grow automatically.)

----------

## 1clue

A SAN with an encrypted filesystem on it?

Do you have really fast networking?

----------

## ManDay

I guess a SAN (i.e. remote block level as szatox said) with encryption may probably be what I'm looking for. As for X-Y: The goal is centralized data storage (employee's data) with no one but the data owner being able to read the data. I.e. neither anyone with access to the storage facility (therfore, the data must be encrypted on the server and not decryptable by the server) nor anyone with full access to the network should be able to decrypt or read the data.

The whole "balance" act I was talking about (and which olek so intentionally or ignorantly misunderstood) concerned a scenario without block level access) like EncFS. In these cases, neither the "encrypt each file individually and place it on the server" nor the "encrypt all files into one big file and place in on the server" are optimal. But since the whole notion of files becomes superflous with SAN, the particular filesystem can then figure it out.

However, the block level solution comes with its own set of restrictions and problems. Assuming we want a pure software solution for TCP/IP and arbitrary sotrage devices on the server, we'd need one of each such SAN drives for each employee and appropriate mechanisms to mount them by permission like CIFS or similar. With a file level storage, the whole thing could simply run on top of CIFS, using all the benefits associated with it. Is iSCSI capable of that? if not, which protocol is? And if there is none, we're back to file level storage, in which case let me repeat my idea:

Any filesystem on the server, mounted with CIFS by the client. The filesystem contains files, each of which encrypts one or more files (or parts thereof) of the encrypted data. (In the case of EncFS, there is a one file<-> one file relation which severely impairs security). The question how (i.e. how many files are encrypted in how many files on the filesystem) is some question of balance between security and performance. For the server it's just a normal CIFS filesystem but the client would need some FUSE to mount the decrypted data. So the question is, whether any such client side FS exists (which does not restrict to one end of the scale from "all files are encrypted into one file" to "each file is encrypted individually").

Depending on the particulars of CIFS, you may replace "file" by any smaller unit of storage which can be transfered from the server.

----------

## 1clue

First a disclaimer:  I am not an expert on this, my only experience with SAN is as a client on an enterprise network.

Second disclaimer, what I'm talking about here is real money.  I don't know what your budget is, but you should be able to get something similar to what I'm talking about with normal hardware and some sweat, even if it's slower.

I think there may be some misconceptions about SAN on this thread.

First, about disks:  I can ask IT to resize a disk on a SAN and they can do so, on the fly.  This implies to me that the SAN is a smart device with something like LVM2 on it, and that the 'disks' are filesystems on that pool.  This is invisible to the client.

Second, about networking:  All the SAN storage I've had access to has a separate interface from the NICs.  The one I actually touched had fiber point-to-point between the SAN and the server.  The research I've done suggests that eliminating tcp/ip for the SAN speeds things up considerably no matter what transfer media you use.  Without exception the single servers I've used (that I asked about) which are SAN clients have 10gbps SAN interfaces and one or more 1gbps NICs for tcp/ip.  Some of the virtualization servers have 10gbps nics and I'm not sure what speed of SAN interface, afraid to ask.

Third, about speed:  All the SANs I've had exposure to use a NIC of some sort which is at least as fast as a local disk, and in general the speed tests I've done with the servers which are SAN clients boast better than sata3 throughput.

Fourth, about hardware:  It's my understanding that a machine which can boot from SAN requires hardware support for booting from a SAN.  Which probably means server hardware.  I don't know more than that, it may be true or not but check it out before you buy.

About price:  Probably each of the SANs I've had some sort of contact with cost more than any car I've ever owned, assuming new prices.  That's pure speculation on my part but a good guess based on what I've seen online for SANs.

My understanding of enterprise SANs is that they have a physical disk pool which is hot swappable (RAID probably) with something like LVM2, and a backup medium which is separate from the physical disks.  They're managed by some sort of software to control which host gets what volumes, and that the volumes are resizable without rebooting either the SAN or the client box, and that resizing is on the block level.  Meaning I ask for so much space and I will get something close to that, not the actual size I requested.  What I get through the wire looks like a physical disk.

I have no experience whatsoever encrypting a filesystem, but to me encrypting the entire filesystem such that you need to decrypt the entire thing before using any part of it makes no sense even on a local device.  It seems to me that block-level encryption is the way to go.  You might consider a system with hardware encryption support on it on each end, like Intel QuickAssist.  http://www.intel.com/content/www/us/en/network-adapters/quickassist-adapter-for-servers.html or the Atom c2*58 processor series has it too.  I just bought a SuperMicro board for use as a router/firewall/VPN/UTM appliance http://www.supermicro.com/products/motherboard/Atom/X10/A1SRM-LN7F-2758.cfm

Based on what you've said here it seems to me that you could have a local drive to boot from and a SAN-based encrypted $HOME, disallowing normal user writes to anything outside $HOME.  IMO you would probably want faster-than-gigabit SAN nics and go point to point.

----------

## Ant P.

 *ManDay wrote:*   

> Not sure whether the other two replies are jokes.

 

Likewise, I wasn't sure if you were trolling with this combination of ridiculously specific requirements, utter ignorance of the subject, and total hostility to the people you're coming to for help.

But now I know thanks to your persistence in the latter. *plonk*

----------

## aahjnnot

 *ManDay wrote:*   

> ...The goal is centralized data storage (employee's data) with no one but the data owner being able to read the data. I.e. neither anyone with access to the storage facility (therfore, the data must be encrypted on the server and not decryptable by the server) nor anyone with full access to the network should be able to decrypt or read the data...

 

In my experience (and I work in financial services so I'm pretty security aware), very few companies go to these lengths to protect employee data. In fact, most companies would feel extremely uncomfortable about storing employee data that they were unable to examine themselves under the right circumstances. What if the employee used the file store to record records of criminal activity? What if the employee stored personal data relating to customers in the file store? What if the employee stored commercially important data in the filestore but somehow became incapacitated? The employer could be in a very difficult position, particularly in a regulated industry. How would the employer comply with information requests from law enforcement agencies, government or regulators?

Maybe you work in an unusual industry where these things don't matter. Maybe you live in a country where it's important or acceptable to hide things from the government. But your proposal would be very, very dangerous for most companies in the Western world.

A more normal solution would be to use a secure filesystem such as NFS with Krb5i security and carefully managed access controls. The server would have full disk encryption and a single administrative user with network users not allowed to sign on. The encryption key and local root password would be stored in a secure key safe (either physical or electronic) and would be accessible only to a small number of appropriately senior employees, two of whom would need to be simultaneously present to unlock the keys. On the rare occasion when it was necessary to restart or log in to the server as root, all access would be under physical supervision. A log, preferably physical, would be maintained of any system access and a security policy would detail the circumstances under which access would be permitted.

----------

## szatox

1clue, your understanding of enterprise SAN is pretty accurate, however not all purposes require enterprise-class.

IP-based SAN (iSCSI) will do fine in many cases. I doubt it would handle a big strained database, but for less demading tasks might be just fine.

To boot over SAN you need hardware capable of doing so. On iSCSI it might be kind of worked-around with PXE, but ManDay never said it has to be bootable. In case of linux, there are kernel modules doing SAN initiator's job and user-mode daemon acting as the target. While target's configuration is a bit awkward, I found it reasonably easy to setup. At least when you're armed with some manuals  :Smile: 

I never needed it on windows, but I suppose you could find some drivers if you needed it.

Oh, and the disk encryption stuff seems to use counter mode or similar, with block number being the counter, so there are no visible patterns, but encryption does not deppend on other blocks contents. The logical position is all that matters, and this one is already known when you access a particular block.

----------

