Asymmetrically encrypted filesystem

Question

I'm dealing with some data that's governed by specific regulations and that must be handled in a specific manner.

I'm finding that this data ends up in some of my log files as a result of the system operating as intended. I'd like to find a way to log messages on the server that receives that data, but to do so in such a way that the data is encrypted as it's written to disk and may not be decrypted by that same server.

My thought is that there should be a filesystem (written as a FUSE system or something - I'm using Linux) that exposes the directory structure as clear text, but writes the contents of the files according to one half of an asymmetric key set. This would permit me to log the messages and queue them to be sent off to a log server where the decryption key resides.

The inefficient (CPU-wise) nature of asymmetric encryption may make this infeasible, but I suspect that there may be a solution out there. I haven't found anything in my searching yet; is there a solution out there that can operate in the described fashion? Thanks for any tips!

Answer 1

I'd recommend you do it in the application layer.

In that case, then move the thread to StackOverflow, however, my answer would be approximately:

• The normal way of using asymmetric encryption on significant amounts of data (i.e. anywhere) is to use it to encrypt a randomly chosen key which is then used to encrypt the rest of the data using a symmetric cipher
• This is because symmetric ciphers are much faster and generally do more of what you want

I'd design it such that the log file was written in chunks which contained a header containing a key encrypted using an asymmetric cipher, which would then be used to encrypt a certain amount of data using a symmetric cipher.

So for example you could use AES / CBC for the log data itself, which is going to be pretty fast (plus there are loads of implementions).

Then every so often, your app discards the key and starts a new "chunk" - once the key is gone out of ram, it cannot then decrypt the previous chunk any more.

So you might use (say) RSA to encrypt (using a public key) the symmetric key for a chunk, which would be securely randomly chosen for that chunk. The symmetric key then stays in memory for a while, until the chunk ends, and it is wiped out.

A filesystem which supported this would be of limited usefuless because you could only mount it write-only or read-only; operating systems don't normally understand the concept of write-only filesystems :)