views:

92

answers:

3

I'm building a server-side application which requires the data the be stored encrypted in the database. When a client accesses the data, it also has to be transferred encrypted. The clients each has a unique login.

My original idea to do this, is to store the data encrypted with a symmetric-algorithm like AES. So when a client wants to access the data the encrypted data is transferred to the client, while the key is encrypted with the public key from the client.

Is this a secure way to do store and transfer the data or is there a better solution to this problem?

Update: If following Søren's suggestion to keep a copy of the AES key encrypted using each client's public key, wouldn't that include the key to be stored somewhere in order to add additional clients or could that be generated in any way?

A: 

That is indeed the common approach, e.g. also used by NTFS file encryption.

Martin v. Löwis
+3  A: 

Secure from what? You need to define your goals more clearly.

The solution would protect the data during transfer, but from your description, the server would have full access to the data (since it'd need to store the AES key unencrypted). In other words, a hacker or burglar with access to the server would have full access to the data.

If secure transmission is what you want, use an SSL / TLS wrapper around the database connection. This is a standard solution from all major vendors.

To secure the data server side, the server should not have the AES key. If the number of clients were limited, the server could store a copy of the AES key for every client, each copy of the key already encrypted with the public key of each client, such that the server never sees the plain text data nor any unencrypted AES keys.

Søren Løvborg
+2  A: 

First you should start by defining some security properties you want to provide, for example:

  1. Is it ok to give different users access to the same secret key? Aka if File1 is AES encrypted with key K, is it a problem if user Alice and user Bob both are given K.

  2. How do I revoke users from the system? (It turns out Bob from scenario 1 is actually a Chinese spy working for our company, how do I securely kick him out of the system).

  3. Does the encrypted data that is saved in the database need to be searched? (This problem is well researched and hard to solve!)

  4. How much (if any) and what plaintext data will be placed into the database to help organize it? Databases expect data to have unique keys associated with them. You need to make sure these keys don't leak information, but are useful enough to retrieve the data later.

  5. How often should secret keys be changed? If you are storing files and multiple users are allowed access to encrypted files, what happens when user X modifies a file? Does the secret key change? Should the new key be sent to all users?

  6. What happens when 2 users modify the same data at the same time? Will the database be able to handle this without modification?

There are many others.

If the server is not trusted and must never see plaintext data, then here's a general overview of a possible solution.

Let the clients managed the crypto completely. Clients authenticate with the server and are allowed to store data into the database. It is the responsibility of the client to make sure the data is encrypted. In this scenario, keys should be saved securely only on the clients computer. If they must be placed elsewhere, a "master key" could be created.

James