Protection of intellectual property (Schema & SQL code)
I want to develop an application using a database server. But I am concerned
that installing it at client's sites will mean that I am potentially
exposing my intellectual property to theft. (I'm in Asia where this sort of
thing is rife).
Would it be true to say that for all database servers (Oracle, SQLServer,
PostgreSQL, Interbase etc) it is impossible to absolutely protect the
intellectual property contained in the schema design and sql code ( not to
mention the data itself)?
Is it true that a database backup can always be restored on a different
server and thus the administrator can gain complete access to schema, code
and all data?
If there is a difference in this respect on various server types, is there a
"league table" of which offer the best security?
Can security be enforced in some way by compelling each user (including
administrator) to always have a digital certificate even if using a restored
copy on a different server?
Hi Michael,
if your concern about theft is really big, you will need
to write a second piece aof software. Translate all column
names in your scheme to col1, col2, .. and tables to tab1, tab2, ..
Of course your SQL need to be adapted. But nobody will
ever be able to make a meaning out of that. So reengineering
will be really tough. But simple copy will still work.
Ulli
mlq@hotmail.com (Michael) writes:
I want to develop an application using a database server. But I am
concerned that installing it at client's sites will mean that I am
potentially exposing my intellectual property to theft. (I'm in Asia
where this sort of thing is rife).
In other words you want to create a black box. Information goes in,
but it only comes out if you get paid. Such a thing is possible, but
only if the customer doesn't get to poke at the box. If they control
the hardware, then you are sunk.
Would it be true to say that for all database servers (Oracle,
SQLServer, PostgreSQL, Interbase etc) it is impossible to absolutely
protect the intellectual property contained in the schema design and
sql code ( not to mention the data itself)?
Yes, that's basically how things work. PostgreSQL, Oracle, SQL
Server, Interbase, and all the rest will happily regurgitate both
"your" schema and your customers data. Many of them (like PostgreSQL)
will even do it in an easy to edit text format if you ask nicely
enough.
Is it true that a database backup can always be restored on a
different server and thus the administrator can gain complete access
to schema, code and all data?
Yes that is true. In fact, it is darn handy. Backups that can't be
installed on a separate machine aren't backups.
If there is a difference in this respect on various server types, is
there a "league table" of which offer the best security?
Security usually means keeping crackers out, not systems
administrators.
Can security be enforced in some way by compelling each user
(including administrator) to always have a digital certificate even
if using a restored copy on a different server?
With special hardware and special hardware such a thing *might* be
possible. For example, the X-Box has been engineered by Microsoft so
that only their software will boot on it. Chances are good that there
is a loophole or a way to trick the system, however.
Chances are also good that your customers won't be interested in a
system with backups that can't be installed on another machine. After
all, what happens if the primary machine fails? They probably also
won't be thrilled by an application that doesn't believe in sharing
data.
Jason
Actually this technique was also used for Java, (as people were going after
the bytecode.) but has been cracked as well.
Given ample time and money, say 100s of programmers in Jail or
for $1 / day, they will figure you out sooner or later.
So perhaps the view should be ... I go so fast that by the time they figure
me
out, I have obsoleted that very technology.
God helps us.... I should've taken econ or something else....
Ulrich Wisser wrote:
Hi Michael,
if your concern about theft is really big, you will need
to write a second piece aof software. Translate all column
names in your scheme to col1, col2, .. and tables to tab1, tab2, ..
Of course your SQL need to be adapted. But nobody will
ever be able to make a meaning out of that. So reengineering
will be really tough. But simple copy will still work.Ulli
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
-------------------------------------------------------------------------
Medi Montaseri medi@CyberShell.com
Unix Distributed Systems Engineer HTTP://www.CyberShell.com
CyberShell Engineering
-------------------------------------------------------------------------
At 02:27 AM 2/17/02 -0800, Michael wrote:
I want to develop an application using a database server. But I am concerned
that installing it at client's sites will mean that I am potentially
exposing my intellectual property to theft. (I'm in Asia where this sort of
thing is rife).
Your software can be copied.
Can security be enforced in some way by compelling each user (including
administrator) to always have a digital certificate even if using a restored
copy on a different server?
If people really want to they can disable the checks on your program.
So even if you give each of them an individual cert (signed by your CA) and
make the program check the cert or decrypt itself using the results of
verifying the cert, people can always step through the program retrieve the
decrypted program and remove the checks and voila cracked program. You'd
still likely know whose copy was cracked but you can't stop the copying
unless as part of it's function the program needs to talk to other entities
that require presentation of a _valid_ unrevoked certificate.
---
There's one thing to consider tho, even in Asia people at certain market
ranges are willing to pay just to know that there can be support and
maintenance. At those levels they may not want to pay a lot, but they
aren't going to copy your stuff from someone else for free and try to get
it to run (the few that are are stupid|nuts|nasty and you don't want to
deal with them anyway). That has been my experience so far.
Applications with DB's stuck in them typically belong in these market
ranges (not all tho). In fact you can often pull the per user/seat license
sort of thing without any software controls - the sales people just need to
pay friendly visits to them from time to time to see whether their needs
have changed (easy sale - they are already using more, so obviously they
need+like it :) ).
So if your application falls within this range, then I don't think you need
to worry too much.
But if it's at the consumer end (where support = wall paper music over the
phone, maintenance = user self upgrades to next version ), then oh well
good luck, maybe your app will be on a CD with a dozen other apps for USD3
at some night bazaar sometime ;)...
Regards,
Link.