2

If I am to store different types of sensitive data, let's say: field1 in Table A and field2 in Table B and the data is unrelated, should I use a different key for each field?

Add information 1: The encryption/decryption is going to take place in the application code and the database will only store the encrypted data.

Add information 2: Right now, I'm planning to use AES-256-CBC and the database is MongoDB.

luizfzs
  • 261
  • 2
  • 12
  • There are many encryption strategies, some builtin to DBs, others implemented by the app. Can you give us more context so that we can help you. – Neil Smithline Apr 01 '18 at 22:53
  • I second the request for more information. Specifically, what type of database are you using? Depending who you're trying to protect data from, it might also be worth considering whether the data may be transparently encrypted by the database (so the application never needs to know it was encrypted), or the application may handle decryption so the database server never has access to the date in the clear. This depends on the level of trust given to the database, whether you need to search on the encrypted data, and how paranoid you are. – nbering Apr 02 '18 at 01:21
  • 1
    Generally using the same key is fine, assuming you are OK with the fact that each field can be decrypted with the same key (should be obvious). You must use unique IVs however, but if the encryption implementation for your database is made correctly, it will handle that for you. – forest Apr 02 '18 at 09:16

2 Answers2

1

Based on the information provided in the update, I would suggest to use the same key for each field. Different keys would be an overkill as you might want to encrypt other fields as well and also it would be cumbersome to map the fields with different keys.

Following points can be considered with this approach :

  • The encryption key is not stored at the same db where encrypted data is being stored. (consider to store in configuration file)
  • The encryption key should be sufficiently long to prevent any brute-force attack on the key itself.
  • Based on the frequency of usage and sensitivity, decide whether to use Symmetric or Asymmetric. (refs : comments)

Edit 1 :

  • If using the config file to store encryption key, make sure to not commit the key accidentally. Instead, commit a dummy key and replace it during deployment.
Procrastinator
  • 51
  • 3
  • -1 for the last point. I can't see any possible reason why symmetric vs asymmetric should be decided on based on "frequency of usage and sensitivity". They have completely different purposes (key exchange vs confidentiality, for example). – forest Apr 02 '18 at 09:12
  • @forest, It's because, symmetric is faster as compared to asymmetric. [https://en.wikipedia.org/wiki/Public-key_cryptography#Computational_cost] Also, please consider the overall answer for the downvote. – Procrastinator Apr 02 '18 at 09:14
  • But why would you ever want to use asymmetric crypto for encrypting local files in a database? It's only useful for doing things like encrypting data over a network where the two parties do not yet have a shared secret. Can you elaborate in your answer why you would ever want to use asymmetric cryptography for locally encrypting fields in a database? – forest Apr 02 '18 at 09:15
  • 1
    Got the point. Thanks for making it clear. Shall update the answer. – Procrastinator Apr 02 '18 at 09:19
  • The machine will serve only this application so I'm planning on leaving the key set as an environment variable. It is the best approach, right? – luizfzs Apr 02 '18 at 13:00
  • 1
    A configuration file with appropriately set file permissions is a better choice. If I recall correctly, environmental variables aren't supposed to be used for confidential information. – Monica Apologists Get Out Apr 02 '18 at 14:07
  • @Adonalsium I found [this](https://security.stackexchange.com/q/14000) which says environment variables are fine. I know I've had to look it up in the past because I've been unsure if it's the same as command line arguments, which are definitely insecure. – AndrolGenhald Apr 02 '18 at 15:51
  • I stand corrected. – Monica Apologists Get Out Apr 02 '18 at 15:52
  • @AndrolGenhald The environmental variables are visible at `/proc//environ`, which have similar permissions to `/proc//cmdline` (and identical permissions with the common `hidepid=2`). A user can view the environment of anyone else under the same user. – forest Apr 03 '18 at 06:03
  • @forest All of my `/proc//cmdline` have permission `444`, while `/proc//environ` have `400`, which is consistent with the answer I linked. I'm not seeing much difference between environ and a config file readable by the user. Is there something I'm missing? – AndrolGenhald Apr 03 '18 at 12:47
  • I think most systems set `hidepid=2` by default now, which makes them both `0400`. – forest Apr 03 '18 at 12:48
1

It depends.

In general, the primary reason for using different keys is: you might want to supply different parts of the data to different subsystems. If there are some columns processed by a system A and some columns processed by a system B, you might want to use different keys for these groups of columns. (This consideration may also apply if one subsystem needs access to all the columns and another to only some.)

If, however, all processing happens within a single subsystem — that is to say, all the keys are distributed together and all parts of the data are always decrypted together —, managing separate keys will not be very beneficial at all in terms of confidentiality maintenance, and near-zero benefits will probably be outweighed by the costs of extra complexity.

So, this is the space axis. However, depending on your context, you might also need to consider the time axis, whereby the encryption keys may change over time, and/or data encrypted with different keys may need to be held in same columns. For example, a combination of a policy of regularly changing the encryption key and the costs of decrypting and re-encrypting a large set of data may necessitate protecting the accessibility aspect of data security by performing the re-encryption process by small steps, which means that during changeover, your system may encounter both data encrypted with the soon-to-expire old key and data encrypted with the recently-issued new one.

Coming back to what you asked — it is pretty unusual for a structured database to not be trusted to have access to data in it, so there are no established best practices for this kind of situations. It is more common to run the whole database on an encrypted data storage, usually in the form of a file system of some sort, or alternatively treat the database as a kind of block device, just serving opaque encrypted blobs whose whole meaning will then be determined in the part of the system which you trust enough to have the cryptographic keys. Analyse, for example, what kind of potential attacks you want to protect your system against. If you are concerned that an attacker may be able to read data out of your database, should you also be concerned that the attacker may be able to insert bogus data, possibly data he might not understand, into your database, or replace good data with bad data or garbage?

dig
  • 355
  • 1
  • 6