Any way to protect your data files from root?

[siliconmike]

Is there a way to protect data files from access by root ?

I have a data-centered website and would like to protect data piracy
from any foot-loose hosting company employee.

Any ideas?

Thanks
Mike

[Thomas Bartkus]

"siliconmike" <si*********@yahoo.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Is there a way to protect data files from access by root ?

I have a data-centered website and would like to protect data piracy
from any foot-loose hosting company employee.

Any ideas?

If the user "root" can't access the data, then no one can. At least under
"nix" systems.

If you park your data on someone elses computer, that someone else *has*
your data. And if you can't find a hosting company you can trust, I think
your only recourse is to not use one. What you are describing is a do it
yourself project. You need to own the server and you need to physically
control access to it.

IOW - root has to be *you*.
Thomas Bartkus

[Gordon Burditt]

>Is there a way to protect data files from access by root ?

Encryption. However, this only works if you *NEVER* have unencrypted
data on any host (or network) that this administrator controls. It
might be an acceptable setup if this admin is storing encrypted
backups (which are encrypted on the active site, then sent to the
backup archival system). You can protect from the admin of the
backup archival system; you can't protect against the active site
admin.

It makes it harder for the admin if the password to decrypt the
data has to be entered by the web page user. This means "authorized
users only", and you can't run things like a public forum site this
way. Of course, the admin could modify Apache to log passwords and
parameters passed to web pages.

Little story from long ago: I once rigged up a version of cron
that read an encrypted crontab, with something like popen("cat
crontab | decrypt key", "r"). I challenged a co-admin to figure
out what it was doing. After a couple of weeks, he said "Go look
at what I did to your secret file". He had done nothing, BUT he
got me to decrypt the file. He had modified the system decrypt
routine to log keys. Then he handed me a printout of the file the
next day.

I have a data-centered website and would like to protect data piracy
from any foot-loose hosting company employee.

Any ideas?

If you are talking about a combination web site/database hosting,
where the web site has to use the (unencrypted) data, it's nearly
impossible. The web site has to have the keys to decrypt the data,
and that info is on the system where the admin can get at it. It
might help a little if the web site and the database site are under
different administrative control (and perhaps in different countries).
Still, the web site MUST have the info needed to access the database.

It is still a good idea to encrypt certain fields of your database,
(such as credit card numbers), in case parts of the data, like an
old database backup WITHOUT all the web content also, ends up in a
dumpster where someone finds it. Also, should you end up in court,
encrypting the credit card numbers demonstrates that you made SOME
effort to protect them against, say, the database being accidentally
made downloadable from the web site and Google indexes it.

Gordon L. Burditt

[siliconmike]

What I plan is to encrypt certain data columns with a key and also
encrypt my scripts that access the data with that key.

Atleast this will provide a level of protection.

What is the most secure algo / function to encrypt the data in this
case ?

Mike

[Gordon Burditt]

>What I plan is to encrypt certain data columns with a key and also

encrypt my scripts that access the data with that key.
Please explain where you keep the key so that the data and scripts
can be used. Or is the point of this that they CAN'T be used (in
which case, why not destroy them?)
Atleast this will provide a level of protection.

What is the most secure algo / function to encrypt the data in this
case ?

If the key is taped to the side of the safe, it doesn't really
matter whether the safe walls are 1 inch of steel or 3 feet of
steel. It's much easier to just find the key and use it.

Gordon L. Burditt

[Malcolm Dew-Jones]

siliconmike (si*********@yahoo.com) wrote:
: Is there a way to protect data files from access by root ?

: I have a data-centered website and would like to protect data piracy
: from any foot-loose hosting company employee.

If your data is really worth protecting, like peoples bank account numbers
etc, then you need to either host the data yourself, or have a carefully
drawn up legal contract with the hosting company that is designed to safe
guard your interests and you need to have ways to monitor and/or audit the
hosting company's use of your data.

There are companies that will happily make that sort of commitment, some
will be more expensive than others.

--

This space not for rent.

[siliconmike]

Gordon Burditt wrote:

What I plan is to encrypt certain data columns with a key and also
encrypt my scripts that access the data with that key.

Please explain where you keep the key so that the data and scripts
can be used. Or is the point of this that they CAN'T be used (in
which case, why not destroy them?)

There are programs like eaccelerator / turck_mmcache that encode
scripts. Their modules then decode it in memory in real time. You don't
need a key here.

Atleast this will provide a level of protection.

What is the most secure algo / function to encrypt the data in this
case ?

If the key is taped to the side of the safe, it doesn't really
matter whether the safe walls are 1 inch of steel or 3 feet of
steel. It's much easier to just find the key and use it.

Gordon L. Burditt

[Gordon Burditt]

>Gordon Burditt wrote:

>What I plan is to encrypt certain data columns with a key and also
>encrypt my scripts that access the data with that key.

Please explain where you keep the key so that the data and scripts
can be used. Or is the point of this that they CAN'T be used (in
which case, why not destroy them?)

There are programs like eaccelerator / turck_mmcache that encode
scripts. Their modules then decode it in memory in real time. You don't
need a key here.

That makes it even easier. Since the script decoders are presumably
already present on the server, then root can let them decode it
in memory and grab it (using a debugger).

Gordon L. Burditt

[siliconmike]

Gordon Burditt wrote:

Gordon Burditt wrote:

>What I plan is to encrypt certain data columns with a key and also
>encrypt my scripts that access the data with that key.

Please explain where you keep the key so that the data and scripts
can be used. Or is the point of this that they CAN'T be used (in
which case, why not destroy them?)

There are programs like eaccelerator / turck_mmcache that encode
scripts. Their modules then decode it in memory in real time. You don't
need a key here.

That makes it even easier. Since the script decoders are presumably
already present on the server, then root can let them decode it
in memory and grab it (using a debugger).

I checked again, in fact turck mmcache actually stores the scripts in
compiled form. It doesn't decode them. So it isn't trivial.

[Gordon Burditt]

>> >There are programs like eaccelerator / turck_mmcache that encode

>scripts. Their modules then decode it in memory in real time. You don't
>need a key here.

That makes it even easier. Since the script decoders are presumably
already present on the server, then root can let them decode it
in memory and grab it (using a debugger).

I checked again, in fact turck mmcache actually stores the scripts in
compiled form. It doesn't decode them. So it isn't trivial.

It may not be trivial, but it's likely to be MUCH easier than even
cracking a 56-bit key, and nowadays the key would be much bigger.

If the scripts can be executed, they can be decoded. Especially
if the module doing the execution is open-source. The result may
be a lot like trying to reproduce the original C out of machine
code: you lose all the meaningful variable names, data types, etc.,
but you could still get something that could be executed and modified.

If the objective is to get the database key out of the script, it
still might be sufficient to use the semi-universal documentation
reader (the UNIX "strings" command) on it. Or you could just run
the script and set a breakpoint at mysql_connect (or the connection
opening function for whatever database is involved) and see what
arguments get passed to it.

Gordon L. Burditt

[siliconmike]

> If the objective is to get the database key out of the script, it

still might be sufficient to use the semi-universal documentation
reader (the UNIX "strings" command) on it. Or you could just run
the script and set a breakpoint at mysql_connect (or the connection
opening function for whatever database is involved) and see what
arguments get passed to it.

Well first, decrypting data has nothing to do with database connection
function.

Once the script fetches the encrypted data from the database, then a
multi-level decryption could be done with a redundant coding style that
can act as a strong deterrent for the debugger.

So I said its not probably trivial. But trivial again is a relative
term.

Mike

[autoquartz]

I'm looking for something similar. I actually got a dedicated server and I would like to somehow hide the data from my system administrator. I have gone through the "You should trust your system administrator" discussion in Servermatrix forum. In my opinion, this is not about trusting the system administrator or not, it is all about separation of duty. The system administrator should have JUST enough access to make sure all the services are running correctly on the server.

I'm gong to use Zend Encoder to encode all the PHP codes and one of the encrypted file will contain a key to decrypt the database data. My concerns are:

- Will this overhead affect the performance a lot?
- How to make this as transparent as possible to the PHP developer?
- Any chance to have PHPMyAdmin to work with encrypted data?

I'm sure Zend Encoder can be cracked to obtain the database key. However, this will require more effort and make the data not as attractive as to be just mysqldump'ed to a file and sold to competitors.

Thanks in advance for any feedback.