Re: How to lose transaction history (xmin values, WAL, etc.)? - Mailing list pgsql-general

On Fri, May 21, 2010 at 6:40 AM, Sam Mason <sam@samason.me.uk> wrote:
> On Thu, May 20, 2010 at 09:33:23PM -0500, Peter Hunsberger wrote:
>> On Thu, May 20, 2010 at 8:03 PM, Richard Walker <richard@softimp.com.au> wrote:
>> > If the hacker gets root access so they can read
>> > the raw database files, they most likely also
>> > have access to the means to decrypt any
>> > encrypted data. This is particularly so if
>> > the database updates are being done by stored
>> > procedures.
>>
>> Only if they also get at the keys.
>
> It's very difficult (with a conventional OS) to remove the *entirety* of
> the server hardware and software from the TCB.  Hence you should assume
> that if PG ever sees a key it's also possible for an attacker to see the
> same key.

Fair enough. The scenario the OP was describing seemed to be a concern
with browsing the database and not at the level of inspecting running
code, but who knows, he hasn't said what he is really trying to
achieve.  There are some hardware level work arounds for parts of
this, but if you're running everything on the same server I doubt that
you're also looking at that kind of scenario.

> The options are pretty much do all crypto away from the database server
> (either client side, or on another server that you can trust) or you
> have to trust (also in the technical sense) the database server itself
> and things become greatly simplified.

Absolutely the best idea, the OP seems to have ruled that out however.
 As such, you can only make things reasonably safe from direct
inspection....

>
>> > If encryption/decryption happens
>> > on a separate (not-also-compromised) client,
>> > then OK.  Do you know of a way to deal with
>> > this if the application is on the same computer
>> > as the database?
>>
>> Can you use an external key store?
>
> How does this help? if the database has been compromised, what would
> stop the attacker from inserting some code that records the responses
> from this "external key store"?
>

Again, I had the impression that code injection did not seem to be the
issue here.  The issue seemed to be inspection of the data in the
database after the fact.  Like I said, it would be good to know what
the real requirements are...

However, that aside, to answer your question;  among other things, the
key request includes a timestamped hash of internal memory to ensure a
non compromised server and the keys store returns functions with
embedded one time keys to do the actual work. The keys are composite
with portions that must match a compile time stored hash (you can't
have a compromised server requesting the key), and at run time the
same hash must be yielded (impossible to know without a previously
compromised server), or you will get garbage.  Replay attacks won't
work since the server will check the time stamp on the original
request (which we already know can't be compromised) before yielding
up the decryption function.  Much of the key exchange process is
essentially standard Kerberos with the client and the server
authenticating themselves to each other as usual, but you do need some
extensions to manage the extra integrity checks and create and manage
the additional message contents.

--
Peter Hunsberger