Securing a database

[kt83313]

My company provides some services online, which now they are planning
to make it offline and sell to customers who can use it in their
networks.

One of our major moneywinners is some data which is stored in a
database. Now, this data inside the database was obtained after paying
through the nose - so the company does not want to disclose the data
in the DB to the outside world - not to mention the lawsuits which the
original providers of data will start which will sink the company if
the data goes out.

Now, the code is in Python - and we have a big problem. How to secure
the data in DB? One idea was to encrypt it and store the password in
the code. I dont believe security through obscurity - and python code
can easily be reverse-engineered too - right?

Is it even possible to secure a data in this case?

KT
--

 

[Diez B. Roggisch]

My company provides some services online, which now they are planning
to make it offline and sell to customers who can use it in their
networks.

One of our major moneywinners is some data which is stored in a
database. Now, this data inside the database was obtained after paying
through the nose - so the company does not want to disclose the data
in the DB to the outside world - not to mention the lawsuits which the
original providers of data will start which will sink the company if
the data goes out.

Now, the code is in Python - and we have a big problem. How to secure
the data in DB? One idea was to encrypt it and store the password in
the code. I dont believe security through obscurity - and python code
can easily be reverse-engineered too - right?

Is it even possible to secure a data in this case?

No. And that has nothing to do with python. If the data is valuable, it
will be decyphered from a compiled piece of code in no time. Believe me,
I work for a company that sells a C++-software with protective measures
of various kinds. It gets hacked. Fact of live.

You could try and raise the bar, as e.g. skype does, with an onion-kind
of code-encryption-scheme. But even *that* is analyzed. And it is
nothing that is done easily and without major impact on your source, so
you might need quite a bit of time to get it right. Is that covered by
the expected revenues?

And even if one doesn't want to hack into the system, if there is an
interface to the data, who stops your users from exploiting that
automatically to access all the data in the DB somehow?

Diez

 

[kt83313]

(e-mail address removed) schrieb:







No. And that has nothing to do with python. If the data is valuable, it
will be decyphered from a compiled piece of code in no time. Believe me,
I work for a company that sells a C++-software with protective measures
of various kinds. It gets hacked. Fact of live.

You could try and raise the bar, as e.g. skype does, with an onion-kind
of code-encryption-scheme. But even *that* is analyzed. And it is
nothing that is done easily and without major impact on your source, so
you might need quite a bit of time to get it right. Is that covered by
the expected revenues?

And even if one doesn't want to hack into the system, if there is an
interface to the data, who stops your users from exploiting that
automatically to access all the data in the DB somehow?

Diez

Thank you very much Diez.
This was my fear.
Anyways, if we can make it real hard for them to analyze also, I think
we are in the good - esp since the clients are not extremely rich
enough to go for professional analyzers --
What is the skype method? The code is not huge - less than 20K LOC so,
code encryption looks somewhat OK - would you be able to direct me to
any hints on this?

One another option that I was thinking was to automatically generate
the password for the database - re-encrypt every 1 hr - and store the
password inside the code itself. Is that possible in Python? i.e.
changing the code itself.

KT
--

 

[Diez B. Roggisch]

Thank you very much Diez.

This was my fear.
Anyways, if we can make it real hard for them to analyze also, I think
we are in the good - esp since the clients are not extremely rich
enough to go for professional analyzers --
What is the skype method? The code is not huge - less than 20K LOC so,
code encryption looks somewhat OK - would you be able to direct me to
any hints on this?

20LOC of pyhon translates to the tenfold in a compiled language I'd guess.

And all I know about the skype-protection I've read from some paper of
some french researches - I think. However, that paper was about
*breaking* the encryption, not about how to write it.

And I'm not an expert in these matters, mind you.

One another option that I was thinking was to automatically generate
the password for the database - re-encrypt every 1 hr - and store the
password inside the code itself. Is that possible in Python? i.e.
changing the code itself.

But wherefrom do you get the *initial* password, or the one used the
last time? What happens if the process dies unexpectedly, leaving the db
in an undefined, half-crypted state with no way to know the new password?

Seriously - if I was assigned the task of doing this thing, I'd seek
help from somebody who has experience in these matters. It's hard to get
right, and easy to get wrong but think one has it right.


Diez

 

[kt83313]

20LOC of pyhon translates to the tenfold in a compiled language I'd guess..

And all I know about the skype-protection I've read from some paper of
some french researches - I think. However, that paper was about
*breaking* the encryption, not about how to write it.

And I'm not an expert in these matters, mind you.


But wherefrom do you get the *initial* password, or the one used the
last time? What happens if the process dies unexpectedly, leaving the db
in an undefined, half-crypted state with no way to know the new password?

Seriously - if I was assigned the task of doing this thing, I'd seek
help from somebody who has experience in these matters. It's hard to get
right, and easy to get wrong but think one has it right.

Diez

I agree Diez.
Anyways, code encryption seems to be a fun thing. I will try to see
whether some papers about Skype is running around.
If I can get it done, then maybe I will try to post the code here.

KT
--

 

[kt83313]

Sounds like you have the "digital rights management" (DRM) problem. As
Diez pointed out, there is no robust software solution. Nevertheless,
many clever people have worked each side, so there's now something of a
body of practice and experience.


I don't think Skype has much to offer here. They're not focused on
selling DRM technology; they sell communication services. Third parties
can write applications on top of those services, which can be protected
by Skype's DRM. (If I'm wrong on that, someone please correct me.)

Diez's noted Skype's use of a layered approach, but there's nothing
special about the notion of layered code encryption in DRM software.
It's been used multiple times, broken multiple times, and patented
multiple times.


Possible it is. Effective it is almost certainly not, at least not
without a whopping bunch of other techniques going vastly beyond that
description.

Look up DRM technology companies, such as CloakWare, Macrovision, and
Cryptography Research.

If you have a modest number of customers, hardware solutions and/or
strict contractual commitments might offer practical solutions.

Thank you very much Bryan.
It does look like this is out of my league.

KT
--

 

[Peter Pearson]

Thank you very much Bryan.
It does look like this is out of my league.

It is out of *everyone's* league. Every company that has
ever wanted to sell movies or music that you can play on
your computer but that you can't post to the Internet has
faced this problem. Many, many millions of dollars have
been spent searching for mitigation. The best you can hope
for is to delay your attacker by some number of months.
That might be enough if the value of your content is
ephemeral, but even that can only be achieved with a big
initial investment, enormous implementation hassles, and
commitment to a never-ending arms race with the pirates.

 

[Bryan Olson]

Thank you very much Bryan.
It does look like this is out of my league.

As Peter Pearson noted, "It is out of *everyone's* league." And Peter
used to work for Cryptography Research, a small company that scored as
high in this league as anyone. Maybe you can advance the state of the
art in DRM; but if so, you can probably make more money on that than on
selling access to this particular database.

Stepping back, KT, you said that your company currently provides an
on-line service backed by this database. Maybe you want to stick with
that. Can you say what prompts you to look at offering off-line access
to your customers?


I've spent most of my career, so far, as a cryptologic engineer, and
I've seen similar problems. For example, the U.S. Postal Service has a
database of valid addresses and address forwarding requests that can
provide reasonable and valuable services, but that they are barred by
law from generally exposing. Users are allowed to check the validity of
a name-and-address, and if they have one, they're allowed to know if the
addressee has forwarded it, and if so, to where.

At the time I got involved with the USPS's FASTforward system, they
offered an Internet service, and an off-line locally-accessible product.
The off-line product was a black-box system -- literally: a PC-class
computer in locked black case, with hardened epoxy gumming up most of
the interface ports. An open SCSI port answered legitimate forwarding
requests, and the CD drive accepted encrypted updates to the database.

A similar scheme might still play, but there's no question that times
have changed. Back then, the USPS system of locked black boxes made
sense. Users numbered more than a hundred but less than a thousand, and
the Post Office required agreement to a contract that protected
individual addresses.

 

[M.-A. Lemburg]

My company provides some services online, which now they are planning
to make it offline and sell to customers who can use it in their
networks.

One of our major moneywinners is some data which is stored in a
database. Now, this data inside the database was obtained after paying
through the nose - so the company does not want to disclose the data
in the DB to the outside world - not to mention the lawsuits which the
original providers of data will start which will sink the company if
the data goes out.

Now, the code is in Python - and we have a big problem. How to secure
the data in DB? One idea was to encrypt it and store the password in
the code. I dont believe security through obscurity - and python code
can easily be reverse-engineered too - right?

Is it even possible to secure a data in this case?

That depends a lot on what you call "secure". The data will have
to get processed by the CPU one way or another and there are lots
of ways to monitor such operations, either through software (debuggers,
loggers, etc.) or hardware (low-level debuggers, signal analyzers, etc.).

The best you can do is make it just a little harder to get at
the data, ie. implement a simple but non-trivial data protection
mechanism, and then use legal means to protect yourself from
any wrong-doing of your customers.

One way to do this, is by encrypting the data for the database
and decrypting it whenever you start the application. If you
use an in-memory database for the application, this will provide
such a simple but non-trivial data protection scheme.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Jan 25 2009)________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/

 

[Aahz]

My company provides some services online, which now they are planning
to make it offline and sell to customers who can use it in their
networks.

How critical is it that this application work completely offline? I
suggest that you seriously consider making your application crippleware
unless it can "call home" -- that is, certain key bits work only with
online access even if the majority of the app is local. This may or may
not include the secure database, but if the data is local, it can still
get hacked.