Re: Looking for advice on database encryption

On Fri, Apr 17, 2009 at 10:33:15AM -0400, Bill Moran wrote:
> The goal is not to trust any one part of the system.
> As a result, we can protect the data across multiple security failures.

As far as I know this isn't a good way to go about designing secure
systems.  You're better off defining a set of plausible attack vectors
and design the system so it's not vulnerable to them.

> For example, backups will actually be encrypted twice.  In order to
> recover data from our backups, an attacker would have to physically
> acquire a tape, then steal or brute-force 2 different encryption
> keys before they could access the data.

OK, so there would be two vectors here, each entity would have their own
secret they use the encrypt the backup.  Breaking the backup requires
the collusion (remember security is normally much easier to break from
the inside) or compromise of both entities.  The question then becomes
what happens with the backup before it's been encrypted by both entities
and how can you ensure that one can't compromise the entire system?

Your trust would therefore be that at most one entity will be
compromised.  Once you've said that you can ask yourself whether
this is appropriate.  Saying that you're encrypting data twice is,
from a security perspective, vacuous because you're leaving open the
possibility of encrypting it twice in series on the same server and
hence an attacker just needs to compromise that one server to recover
both keys and break the system.

If you're defining this single server as trusted then you're assuming
you're capable of protecting this server from attacks.  Other
definitions would partition the server into parts (say different user
accounts, and then you need to worry about privilege escalation) and
say that some parts are trusted.  The "root" user is by definition
a trusted entity in any Unix system; Microsoft tried to break this
assumption in Windows but I think they gave up in the end.  The "root"
user will normally carry more authority[1] than normal users, but it
should not need absolute authority as is does in conventional operating
systems.

> In the end, the only person that should be trusted with the data are
> the users who own the data.  That person will explicitly grant access
> to their data to program administrators, the software will simply
> facilitate the process.

OK, but more definitions are required to understand what you mean by
this statement.  You don't need to send them all here, but if I was
designing something similar to what you are I'd want to know what I was
up against.

> We put as many layers as we can everywhere.  Usually this is limited
> when we start hitting performance issues and have to remove a layer
> to keep performance where it needs to be.  The goal is to have as
> many layers as possible while keeping the system as performant as
> the client expects.

I, personally, wouldn't recommend doing things this way.

I'd define where you put your trust and design around that.  You'll
get a much stronger system and you'll know where to invest time in
protecting it because you know what you trust and if those items are
compromised everything falls down.  If you don't know what you're
trusting you don't know where to expend the effort.

> We only get one shot at this.  If there's a data leak, a lot of
> people are going to be very upset and we're going to be out of
> business, so we're implementing the tightest security possible
> at every layer.  This thread is only one part of the overall
> process as it specifically relates to the database layer.

Yes, that sounds reasonable and to be expected.


Hope that's all somewhat helpful!


--
  Sam  http://samason.me.uk/

 [1] I'm using "authority" in a technical sense meaning the set of
 actions that an entity can directly, or indirectly by talking to other
 actor in the system, cause to occur.  Strictly speaking from a security
 perspective there is no difference between a normal user and root in
 UNIX system because of the presence of various privilege escalating
 mechanisms (i.e. set suid bit on executables).  In practise it's OK,
 but not safe, to assume that the system is configured in a way that
 this doesn't occur and any occurrences are "bugs".