On Fri, May 21, 2010 at 6:40 AM, Sam Mason <sam@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
