How to use 'key material' so that multiple people can access protected files?

Question

I'm not sure if this is the right SE to ask this question, but it seems more I have a database of files that needs to be encrypted such that multiple people with different passwords/logins to this remote system can access the same files without entering a second set of credentials.

Specifically, I need to be able to support:

• multiple users accessing the 'plaintext' version of a single file that's been encrypted once
• revokation of a single user's rights (if they get fired, etc)
• allow a user who has forgotten their password to get a new password (ie, password resets)
• ideally, allow for remote searching/sorting of such encrypted files while minimizing the ability for an attacker to intercept credentials.

My knowledge of security is theoretical at best; I've done some dongle encodings (well aware that crackers will destroy the security given enough time), but this kind of distributed system is a bit beyond me.

My current idea is:

• have a certificate file that serves to decode the remotely encrypted files. This certificate is encrypted by the user's username/password.
• users log in remotely prior to trying to decrypt the certificate, so if they cannot log in (ie, they are no longer working there, whatever), then they can't get at the certificate. This is extremely weak, since they should be able to decrypt the certificate anyway if they're savvy.
• for remote searching/sorting of these files, do date range presorting of the files. This technique is only valuable because we do not expect more than 5-10 additions to the database per user per day (and even that is ridiculously prolific), so getting entries from the last three days, three weeks, etc, supports our most expected use case. Then decryption/searching/sorting of these files can be done locally.
• for password reassignments, they need to get another encrypted certificate with the new username/password. That means that someone else on the site (the administrator, or whomever) must have access to a plaintext version of the certificate to provide the user with a new certificate, which means that new passwords must be assigned by an administrator. Which I'm OK with.

This approach is bad for a few reasons:

• savvy users can decrypt their old certificate using their credentials and knowledge of the encryption/decryption routine. This is not too big of a deal, because they cannot access remote data anyway, since their logins will fail.
• remote searching/sorting will be painful.
• if everyone on the site loses their password, they lose all their data. I'm tending to think that if customers want this level of security, then they also want this kind of consequence.

So I ask this community — does this approach sound feasible? Is there a package or group of utilities I should be looking at for this (or some other, more improved) approach?

To be clear, this system will store encrypted data remotely, and the user will then access that data. I can make the user client be on any system, but the idea is that it will be a program that we give to the user to access the remote data. The server should never have plaintext data.

So, if the user is on Windows, then they will have a client, a certificate, and login credentials. The certificate would be encrypted with those credentials, so that it can be decrypted and used to read data from this remote system. I cannot change what OS the user will have.

Answer 1

These are different security levels and they need different solutions:

• Encrypting file ensures that anyone - without the proper key - could steal it but not read it.
• Having a bunch of users to access some files with some credentials is a different matter.

If a user can access the plaintext version of a file then it does not matter if that file was ever encrypted as your system (and file encryption) is transparent to the user. When she logs in, she sees all the files she has access to, and she won't even know if those files are encrypted or not.

A linux system can provide everything you need here. Create different users, even set them up to log in with certificate then allow them to access files with proper user/group rights. If a user should be able to upload encrypted files then create an RSA keypair, and distribute the server's public key to the users. With that key they can encrypt a file, and it can be decrypted on the server side.

Answer 2

This may sound a bit off-topic but I attended an open lecture that explains the fundamentals of a system that provides what you need. I'll share what I've heard.

There were several parties involved:

• Bob and Alice (corporate employees :-) )
• A key escrow

So let's say that Bob wants to share a file for him and Alice. What he do is the following:

• he generates a random key, Kf;
• he encrypts the file F with Kf once (symmetric encryption is used, e.g. AES in CBC mode or something similar);
• he encrypts the Kf with his own public key, the public key of Alice and also the public key of the key escrow;

All this happens "offline", e.g. no need to contact the key escrow or Alice. Now Bob and Alice may share the same file by decrypting Kf with their private keys. If Bob gets fired, looses his password or his permissions need to be revoked the key escrow kicks in and changes the records created above (this may sometimes include changing the Kf and re-encrypting the file).