Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

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).

share|improve this answer
    
I guess this is where my understanding gets fuzzy. Is Bob making three encrypted copies of Kf? One for himself (say, Kf'), one for Alice (say, Kf''), and one for Escrow (Kf''')? So Alice decrypts Kf'' with her private key, but cannot decrypt Kf''' since she doesn't have escrow's private key? Or can Bob create a Kf' that is encrypted with all three public keys, and then Alice can read Kf' with just her private key? Because if I have to make Kf' through Kf(n) with the addition of Charlie, Doug, Ethan, Frank, etc, then this system would not scale well... –  mmr May 19 '12 at 14:32
1  
In the scenario the key Kf was only one and it was encrypted with the public keys of all three players (we have three key records + one encrypted file). When the file is shared to Charlie, Kf is encrypted with Charlie's public key too. (Four records and the file remains the same). This sounds pretty scalable to me... But again - I have no real experience with that, I just share what someone else told me :-) –  lucho May 20 '12 at 18:00
    
sounds like I need to read about public key encryption then, because that seems like freakin' magic to me. –  mmr May 20 '12 at 21:34
add comment

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.

share|improve this answer
    
I see what you're saying about the plaintext certificate-- basically, if I go with this process, I'll need the two levels, and block out any former users from getting their hands on data. Also, I cannot control the platform users have, as this is accessing remote data. I'll update the question to reflect that. –  mmr May 18 '12 at 23:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.