Thread: Re: function body actors (was: viewing source code)

"Merlin Moncure" <mmoncure@gmail.com> writes:
> On Dec 20, 2007 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So if you want something other than endless arguments to happen,
>> come up with a nice key-management design for encrypted function
>> bodies.

> Maybe a key management solution isn't required.  If, instead of
> strictly wrapping a language with an encryption layer, we provide
> hooks (actors) that have the ability to operate on the function body
> when it arrives and leaves pg_proc, we may sidestep the key problem
> (leaving it to the user) and open up the doors to new functionality at
> the same time.

I think you're focusing on mechanism and ignoring the question of
whether there is a useful policy for it to implement.  Andrew Sullivan
argued upthread that we cannot get anywhere with both keys and encrypted
function bodies stored in the same database (I hope that's an adequate
summary of his point).  I'm not convinced that he's right, but that has
to be the first issue we think about.  The whole thing is a dead end if
there's no way to do meaningful encryption --- punting an insoluble
problem to the user doesn't make it better.

(This is not to say that you don't have a cute idea there, only that
it's not a license to take our eyes off the ball.)

            regards, tom lane

On Dec 21, 2007 12:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
> > On Dec 20, 2007 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> So if you want something other than endless arguments to happen,
> >> come up with a nice key-management design for encrypted function
> >> bodies.
>
> > Maybe a key management solution isn't required.  If, instead of
> > strictly wrapping a language with an encryption layer, we provide
> > hooks (actors) that have the ability to operate on the function body
> > when it arrives and leaves pg_proc, we may sidestep the key problem
> > (leaving it to the user) and open up the doors to new functionality at
> > the same time.
>
> I think you're focusing on mechanism and ignoring the question of
> whether there is a useful policy for it to implement.  Andrew Sullivan
> argued upthread that we cannot get anywhere with both keys and encrypted
> function bodies stored in the same database (I hope that's an adequate
> summary of his point).  I'm not convinced that he's right, but that has
> to be the first issue we think about.  The whole thing is a dead end if
> there's no way to do meaningful encryption --- punting an insoluble
> problem to the user doesn't make it better.

Well, there is no 'one size fits all' policy. I'm still holding out
that we don't need any specific designs for this...simply offering the
example in the docs might get people started (just thinking out loud
here):

create function encrypt_proc(proname text, prosrc_in text, prosrc_out
out text) returns text as
$$
  declare
    key bytea;
  begin
    -- could be a literal variable, field from a  private table, temp
table, or 3rd party
    -- literal is dangerous, since its visible until 'create or
replaced' but thats maybe ok, depending
    key := get_key();
    select magic_string || encode(encrypt(prosrc_in, key, 'bf'),
'hex'); -- magic string prevents attempting to unencrypt non-encrypted
functions.
  end;
$$ language plpgsql;

-- ordering of actors is significant...need to think about that
alter language plpgsql add actor 'encrypt_proc' on input;
alter language plpgsql add actor 'decrypt_proc' on output;

If that's not enough, then you have build something more structured,
thinking about who provides the key and how the database asks for it.
The user would have to seed the session somehow (maybe, stored in a
temp table?) with a secret value which would be translated into the
key directly on the database or by a 3rd party over a secure channel.
The structured approach doesn't appeal to me much though...

The temp table idea might not be so hot, since it's trivial for the
database admin to see data from other user's temp tables, and maybe we
don't want that in some cases.  need to think about this some more...

merlin

I have similar patch and it works. There is two isues:

* we missing column in pg_proc about state (not all procedures are
obfuscated), I solved it for plpgsl with using probin.
* decrypt is expensive on language handler level. Every session have
to do it again and again, better decrypt in system cache or somewhere
there.

Regards
Pavel Stehule

On Dec 21, 2007 3:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I have similar patch and it works. There is two isues:
>
> * we missing column in pg_proc about state (not all procedures are
> obfuscated), I solved it for plpgsl with using probin.

I was hoping to avoid making any catalog or other changes to support
encryption specifically.  Maybe your patch stands on its own
merits...I missed the original discussion.  Do you think the code you
wrote can be adapted to do other things besides encryption?

> * decrypt is expensive on language handler level. Every session have
> to do it again and again, better decrypt in system cache or somewhere
> there.

Doesn't bother me in the least...and caching unencrypted data is
scary.  Also, aes256 is pretty fast for what it gives you and function
bodies are normally short.  The real issue as I see it is where to
keep the key.  How did you handle that?

merlin

On 21/12/2007, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Dec 21, 2007 3:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > I have similar patch and it works. There is two isues:
> >
> > * we missing column in pg_proc about state (not all procedures are
> > obfuscated), I solved it for plpgsl with using probin.
>
> I was hoping to avoid making any catalog or other changes to support
> encryption specifically.  Maybe your patch stands on its own
> merits...I missed the original discussion.  Do you think the code you
> wrote can be adapted to do other things besides encryption?
>

I don't know. It was fast hack that just works. It hat to do
obfuscation, and it do it well.

> > * decrypt is expensive on language handler level. Every session have
> > to do it again and again, better decrypt in system cache or somewhere
> > there.
>
> Doesn't bother me in the least...and caching unencrypted data is
> scary.  Also, aes256 is pretty fast for what it gives you and function
> bodies are normally short.  The real issue as I see it is where to
> keep the key.  How did you handle that?
>
> merlin
>

Simply. I use for password some random plpgsql message text and
compile it. I though  about GUC, and about storing password in
postgresql.conf. It's equal to protection level. We cannot protect
code on 100%. If you have admin or superuser account and if you know
some internal, you can simply get code.

http://blog.pgsql.cz/index.php?/archives/10-Obfuscator-PLpgSQL-procedur.html#extended

sorry for czech desc

Pavel

On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote:

> whether there is a useful policy for it to implement.  Andrew Sullivan
> argued upthread that we cannot get anywhere with both keys and encrypted
> function bodies stored in the same database (I hope that's an adequate
> summary of his point).

It is.  I'm not a security expert, but I've been spending some time
listening to some of them lately.  The fundamental problem with a system
that stores the keys online in the same repository is not just its potential
for compromise, but its brittle failure mode: once the key is recovered,
you're hosed.  And there's no outside check of key validity, which means
attackers have a nicely-contained target to hit.

> I'm not convinced that he's right, but that has to be the first issue we
> think about.  The whole thing is a dead end if there's no way to do
> meaningful encryption --- punting an insoluble problem to the user doesn't
> make it better.

Well, one thing you could do with the proposal is build a PKCS#11 actor,
that could talk to an HSM.  Not everyone needs HSMs, of course, but they do
make online key storage much less risky (because correctly designed ones
make key recovery practically impossible).  So the mechanism can be made
effectively secure even for very strong cryptographic uses.

Weaker cases might use a two-level key approach, with a "data-signing key"
online all the time to do the basic encryption and validation, but a
key-signing key that is always offline or otherwise unavailable from within
the system.  The key signing key only authenticates (and doesn't encrypt)
the data signing key.  You could use a different actor for this, to provide
an interface to one-way functions or something.  This gives you a way to
revoke a data-signing key.  You couldn't protect already compromised data
this way, but at least you could prevent new disclosures.

Yes, I'm being hand-wavy now, but I can at least see how these different
approaches are possible under the suggestion, so it seems like a possibly
fruitful avenue to explore.  The more I think about it, actually, the more I
like it.

A