2

An application is required to store sensitive data* on each user. Additional columns are added to the database which store cyphertext encrypted on the application server. The algorithm of choice is symmetric (AES) and a single key (assume that this key is correctly stored and distributed to the application servers).

My initial reaction to this design that I would favour using a different AES key per row, and storing each key encrypted with an asymmetric key next to the cyphertext.

Is my initial reaction correct? Would treating each database row as a "session" be more secure?

*Not your grandma's cookie recipe level. End of company level stuff. Ideally the system should be secure against information disclosure by anyone person inside or out of the company, or at least limited.

Improve this question
3
  • Who's supposed to be able to read that data after it's been stored?
    – user2313067
    Dec 15, 2014 at 17:56
  • The goal of securing information theft from insiders is impossible to reach (unless nobdy can access the data). Other than that, your gut feeling is in some way right. A single key for the database means anyone who is in possession of the one key can read anything and everything. Someone in possession of the key for one record can read exactly that one record. Of course you would never actually give the key to anyone, but only allow access via a rigidly controlled and audited interface. Still, a key per record doesn't really cost much (a few bytes). The bigger problem is that if people ...
    – Damon
    Dec 16, 2014 at 11:03
  • ... can access the data in some way (and they presumably have to, one way or another, or you don't need to collect the data in the first place) then they have the data even if it's not in the database. So they can as well run away with it to a competitor. Nothing you can do to stop them, other than lawyer up, harsh contracts with high penalties, and a forensic to track them down.
    – Damon
    Dec 16, 2014 at 11:06

2 Answers 2

Reset to default
1

The risk isn't about the number or type of keys.

The risk is about where you're going to store those keys. Assuming your application needs to access the database, it will need a copy of those keys. If those keys sit on the application server somewhere, they can be stolen.

Until you tell me where the keys will be stored, your idea is simply creating more complexity. It's security through obscurity.

Improve this answer
0

The risk is you have one key on multiple servers (from what I understand). If it's not encrypted and someone who shouldn't have it got it, then you have a problem. That being said, AES is very safe if used with randomized IVs.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .