Key distribution advice

Question

I have been thinking for days about that problem! The application is based on a student system management. I am implementing database encryption on a column level and The encryption occurs at the application level.

The administrator sets the columns that are to be encrypted in a win app I will make. Aes encryption is used to encrypt the columns. In the win app, I use RSA public key to encrypt the aes key, and store the encrypted key in the database. I then store the private key in a flash drive. The authorized user will use the private key file to decrypt the aes key and hence decrypt the columns.

My problem is this:

1. Suppose I have more than one user who needs access to these sensitive columns, then my plan does not seem very productive because how can I store the private key to many flash drives at the same time, say 10 flash drives??

2. Also, if i decide to add a user to access the columns, how to give him the private key? Or if I remove one user, thrn I should change the private key of all the rest of users.....

Please help! I have been thinking about that for days!

Answer 1

For the specific situation you are alluding to, using a symmetric key and RSA keys is the right path. Namely:

• Data is encrypted with symmetric key K (with AES or some other algorithm which does the job).
• Every user who should have access to the data has a RSA key pair. Each user has his own key pair, distinct from that of any other user. Let's call Pu the public key of user u (and Su the corresponding private key).
• K is asymmetrically encrypted (RSA) with the public key of each user. This means that the database contains several values E_Pu(K) (encryption of K with the public key of user u).
• When a user wants to access the data, he uses his own private key Su (from his flash drive) to decrypt his value: D_Su(E_Pu(K)) = K. With K, the user can access the encrypted data.
• When you want to add a new user v, you generate the new key pair for that user (Pv, Sv) with the private key stored on a new flash drive which you give to the user. You also encrypt K with Pv and add the new E_Pv(K) to the list of such values in the database.

Removing a user is tricky, because of a general fact: you cannot enforce forgetfulness. Any user who had access to the data at some point could have grabbed a copy of the whole (decrypted) data and still remember it. The best you can do is to make sure that the removed user will not have access to the new data added after the eviction of that user. There are thus two methods to revoke user u data access:

• The fast but incomplete method is to simply remove E_Pu(K) from the list of stored values. This will be sufficient to deny subsequent access from user u if that user is honest and did not keep a backup of E_Pu(K) (or, simply, a backup of K).

• The thorough method is to generate a new master key K', decrypt all the data, reencrypt it with K', and encrypt K' with the public keys of all users except u. The database will then contain E_Pv(K') for all users v except u. This effectively locks out user u from any new data element.

The system described above can accommodate smart cards in lieu of "flash drives". There is not need for any entity other than user u to actually access the private key of user u.

Note: all of the above is about controlling read access to the data. Controlling write access, detecting alterations, duplications or suppressions is another matter.