Subject Re: [Firebird-Architect] Feature Request - Encrypted Stored Procedures
Author Geoff Worboys
>> It could be. Any idea on how the security plug-in could get
>> the decrypt key?

> There could be a standard key defined in the default security
> plug-in for general use, *if* users wanted to overwrite this
> then they could provide a new security plug-in with a new key
> or add a new chained plug-in which overrides default behaviour
> by providing a new key.

I dont quite understand where the security lies in this config.

I presume we are talking about encrypting the BLR (as well as
the source if it exists I guess). Encrypting just the source
is a waste, since reverse-engineering the BLR is not difficult.

So if we have the BLR encrypted the engine must be able to
decrypt it in order to execute it. So we then talk about
really clever ways of obtaining the key - but how clever will
depend on who you are trying to safeguard against.


AFAICT most developers want to encrypt their stored procedures
to protect them from pilfering by the users of the database.
I guess the other situation is when the database gets out from
the authorised users site (but if the database does, you will
need to assume that the security plugin and config files will
as well).

The second situation you may be able to protect against by
hardware options that supplies the key - the software wont
decrypt unless the hardware device is attached.

But to protected against "authorised" users becomes next to
impossible. If I want to get the decrypted BLR I just put in
my own special version of the engine that outputs the BLR
returned from the security plugin.

I guess you can try compiling your own copy of the engine with
the (closed source) security plugin statically linked - so the
plugin cannot be attached to a separately compiled engine.

That might work fairly well, its much harder to reverse
engineer machine executable code (not difficult to do, but
more difficult to make sense of). Then again, I may be showing
my ignorance, perhaps this would be easy to do too (it is
most probably easier than a brute force attack on the
encryption).


So it seems we are still talking security by obscurity, its
just a matter of how obscure you need it to be (and what point
the obscurity becomes pointless).

--
Geoff Worboys
Telesis Computing