Threat models for DB cryptography (Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key) Management Service (KMS)

On Thu, Jun 21, 2018 at 07:46:35PM -0400, Bruce Momjian wrote:
> Agreed. I can see from this discussion that we have a long way to go
> before we can produce something clearly useful, but it will be worth it.

Let's start with a set of threat models then. I'll go first:

1) storage devices as the threat
a) theft of storage devices
b) malicious storage device operators

2) malicious backup operators as the threat

3) malicious servers as the threat
a) compromised servers
b) insider threat -- rogue admins

4) malicious clients as the threat
a) compromised clients
b) insider threat

5) passive adversaries on the network as the threat

6) active adversaries on the network as the threat

7) adversaries on the same host as the server or client

Am I missing any?

For example, modern version control systems that use a Merkle hash tree
have malicious servers as part of their threat model. Git clients, for
example, can detect non-fast-forward history changes upstream.

For another example, DNSSEC also provides protection against malicious
servers by authenticating not the servers but the _data_. DNSSEC is a
useful case in point because it's effectively a key/value database that
stores somewhat relational data...

Clearly PG currently covers threat models 4 through 7:

- passive adversaries on the network (addressed via TLS)
- active adversaries on the network (addressed via TLS)
- local adversaries (addressed by standard OS user process isolation)
- malicious clients (addressed via authentication and authorization)

(1) and (2) can be covered externally:

- protection against malicious storage or backup operators is trivial
to provide: just use encrypting filesystems or device drivers, and
encrypt backups using standard technologies.

One shortcoming of relying on OS functionality for protection against
malicious storage is that not all OSes may provide such functionality.
This could be an argument for implementing full, transparent encryption
for an entire DB in the postgres server. Not a very compelling
argument, but that's just my opinion -- reasonable people could differ
on this.

PG also authenticates servers, but does nothing to authenticate the data
or functions of the server. So while PG protects against illegitimate
server impersonators as well as TLS/GSS/SCRAM/... will afford, it does
not protect against rogue server admins nor against compromised servers.

That leaves (3) as the only threat model not covered. It's also the
most challenging threat model to deal with.

Now, if you're going to protect against malicious servers (insiders)...

- you can't let the server see any sensitive plaintext (must encrypt it)
- which includes private/secret keys (the server can't have them, only
the clients can)
- you have to not only encrypt but provide integrity protection for
ciphertext as well as unencrypted plaintext
- decryption and integrity protection validation can only be done on
the client (because only they have the necessary secrets!)

There are a lot of choices to make here that will greatly affect any
analysis of the security of the result.

A full analysis will inexorably lead to one conclusion: it's better to
just not have malicious servers (insiders), because if you really have
to defend against them then the only usable models of how to apply
cryptography to the problem are a) Git-like VCS, b) DNSSEC, and both are
rather heavy-duty for a general-purpose RDBMS.

So I think for (3) the best answer is to just not have that problem:
just reduce and audit admin access.

Still, if anyone wants to cover (3), I argue that PG gives you
everything you need right now: FDW and pgcrypto. Just build a
solution where you have a PG server proxy that acts as a smart
client to untrusted servers:

+---------------+ +----------------+
+--------+ | | | |
| | | postgres | | postgres |
| | | (proxy) | | (real server) |
| Client |---->| |------>| |
| | | | | |
| | | (keys here) | | (no keys here) |
+--------+ | | | |
+---------------+ +----------------+

In the proxy use FDW (to talk to the real server) and VIEWs with INSTEAD
OF triggers to do all crypto transparently to the client.

Presto. Transparent crypto right in your queries and DMLs.

But, you do have to get a number of choices right as to the crypto, and
chances are you won't provide integrity protection for the entire DB
(see above).

Nico
--