Clarification

[Ravi Shankar]

Dear all,

Assume that I have an application called "Generator", which generates some
output format, not necessarily XML. The output generated is going to be used
by the customer for uploading to a server. I cant change any part of the
application used by the customer, for example I cannot plugin an adapter of
decrypter etc in the file upload program used by the customer.

A strange requirement:- how can I make sure that the customer is using the
output generated from my application only for uploading to the server, but
the customer is not using for sending to another application or customer is
not sending as attachment through SMTP, or FTP etc etc ?

The purpose is that when I sell my Genrator tool, I want the customer to use
that tool only for the intended purpose of uploading to a server, and not
for anything else. How can I prevent from happening programmatically? If any
veterans there had seen such a scenario, please advise, thanks

Note that I cannot encrypt the output generated and decrypt later when the
client is uploading, since, I can't control or change any part of the
application used by the customer, thanks

Best regards,
Ravi

 

[Chris Uppal]

Assume that I have an application called "Generator", which generates some
output format, not necessarily XML.
[...]
Note that I cannot encrypt the output generated and decrypt later when the
client is uploading, since, I can't control or change any part of the
application used by the customer, thanks

Do you mean that you can't control how the customer does the upload, or do you
mean that the "generator" program itself is not in your control ?

If the generator program is under your control then why not just generate
encrypted output (encrypted with a public key) that you will then decrypt on
your server (using the corresponding private key). Of course, a reasonably
ingenious customer will still be able to circumvent the restiction.

If the generator program itself is not under your control then I don't think
there's any way you can even get close to what you are asking for. You'll just
have to trust your customers.

-- chris

 

[=?ISO-8859-1?Q?Karl_=D8ie?=]

One rude way to do this is to allow the clients to run the Generator on
your server via terminal services. Then lock down the terminal and strip
it for any means of sending the output anywhere else.

What kind of app is the Generator? If its a small utility you could wrap
it in a webservice and allow clients access to the service only. If its
a full client app i think terminalserver is the best bet i can think of.

Karl Øie

 

[Oliver Wong]

Assume that I have an application called "Generator", which generates some
output format, not necessarily XML. The output generated is going to be
used by the customer for uploading to a server. I cant change any part of
the application used by the customer, for example I cannot plugin an
adapter of decrypter etc in the file upload program used by the customer.

A strange requirement:- how can I make sure that the customer is using the
output generated from my application only for uploading to the server, but
the customer is not using for sending to another application or customer
is not sending as attachment through SMTP, or FTP etc etc ?

The purpose is that when I sell my Genrator tool, I want the customer to
use that tool only for the intended purpose of uploading to a server, and
not for anything else. How can I prevent from happening programmatically?
If any veterans there had seen such a scenario, please advise, thanks

Note that I cannot encrypt the output generated and decrypt later when the
client is uploading, since, I can't control or change any part of the
application used by the customer, thanks

I'm not sure I understand: You CANNOT modify any of the source code of
Generator, and yet you want to behaviour of Generator to differ from its
current behaviour?

- Oliver

 

[Roedy Green]

The purpose is that when I sell my Genrator tool, I want the customer to use
that tool only for the intended purpose of uploading to a server, and not
for anything else. How can I prevent from happening programmatically? If any
veterans there had seen such a scenario, please advise, thanks

If the server is not yours, then of course the customer can do
whatever he wants with the uploaded data.

Uploaded data may go through a proxy or a router. There is nothing to
stop such an intermediate beast from taking a copy selectively of
whatever flows through.

TCP/IP was designed to make it easy to insert various processes en
route.

 

[Wibble]

If the server is not yours, then of course the customer can do
whatever he wants with the uploaded data.

Uploaded data may go through a proxy or a router. There is nothing to
stop such an intermediate beast from taking a copy selectively of
whatever flows through.

TCP/IP was designed to make it easy to insert various processes en
route.

It sounds like you may need a legal solution, not a technical one.

 

[Ravi Shankar]

HI all,

Thanks a lot for your answers. Just to clarify, Generator is the application
I am writing, hence I have full control on that.

Thanks and regards,
Ravi

 

[Chris Smith]

Thanks a lot for your answers. Just to clarify, Generator is the application
I am writing, hence I have full control on that.

So, let's get this straight. Correct me if I'm wrong about this.
FIRST, the user will run Generator (your code) and create an XML file.
SECOND, the user will upload that XML file using something other than
Generator. Is that right?

Now, do you control the server? If so, then read Chris Uppal's
response. The answer isn't perfect, but it at least protects you from
users without the skill or determination to reverse engineer and modify
the code of the Generator application.

If you don't control the server, then give up on technical answers. You
can't generate a file and then indefinitely keep watch over what happens
with the future of that file. And I'm glad that you can't. If and when
the insidious "trusted computing" architectures come around, you might
be able to do this... but I and many others are fighting to be sure that
day never comes.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

So, let's get this straight. Correct me if I'm wrong about this.
FIRST, the user will run Generator (your code) and create an XML file.
SECOND, the user will upload that XML file using something other than
Generator. Is that right?

At this point, the OP is already screwed. If the user uploads that XML
file using something not under the OP's control, then there's nothing to
stop the user from sending that XML as an e-mail attachment to all his/her
friends.

- Oliver

 

[Chris Smith]

At this point, the OP is already screwed. If the user uploads that XML
file using something not under the OP's control, then there's nothing to
stop the user from sending that XML as an e-mail attachment to all his/her
friends.

Yes, I think you're right. If the OP is in charge of the server, then
the file could be securely encrypted... but that would only prevent the
file from being read by other people. It could still be shipped around
without restriction. I missed that requirement in the original.

(And, of course, the concerns about reverse-engineering the Generator
app still apply... so the encryption could be circumvented.)

One option that hasn't been mentioned here is to convert the Generator
app into a web-based or client-server application with a trusted server.
This could be made truly secure, if and ONLY if it's sufficient for the
user to work with certain summary information that isn't security-
sensitive, while the sensitive information could be associated with the
document transparently by the server. Instead of "uploading" the file,
the Generator web app would need an option to securely transmit the
application to the "true" server (or, if it is the true server, to just
do whatever needs to be done with the completed document). The
sensitive data would never be in the hands of the user, so would never
be at risk.

Of course, that depends on a certain nature of data such that the
sensitive information doesn't need to be directly seen by the user, and
there is a non-sensitive view of the data that's sufficient for all user
tasks. If that requirement isn't fulfilled, then you absolutely NEED to
have some trust in the user with access to the data; otherwise, a secure
is just plain impossible, even theoretically.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

Yes, I think you're right. If the OP is in charge of the server, then
the file could be securely encrypted... but that would only prevent the
file from being read by other people. It could still be shipped around
without restriction.

I'm finding it very difficult to imagine a scenario where this would be a
problem (assuming that client-side execution is OK in the first place, of
course).

Of course, that depends on a certain nature of data such that the
sensitive information doesn't need to be directly seen by the user, and
there is a non-sensitive view of the data that's sufficient for all user
tasks.

But then, I'm also having difficulty imagining a (legitimate) scenario where an
application running on a client's machine has access to data that the client
should not, and would not, be able to share as freely as /they/ wish. (Crash
dumps and similar, perhaps -- they might contain data that neither party would
wish to see splashed around ?)

-- chris

 

[Ravi Shankar]

Dear Chris,

You had said it - I have implemented as a web based application. After
translation, I had designed the third party application as one which will
call a servlet for the translated file. When calling the servlet, I made
configuration in web server such that only the calls from a particular IP
are allowed, otherwise webserver will reject it.

Webserver will be in DMZ of the company, app server behind a firewall. Calls
cannot come to app server directly, hence no possibility to call servlet
directly.

Solved - Kudos to J2EE

Thanks and regards,
Ravi

 

[Oliver Wong]

I'm finding it very difficult to imagine a scenario where this would be a
problem (assuming that client-side execution is OK in the first place, of
course).



But then, I'm also having difficulty imagining a (legitimate) scenario
where an
application running on a client's machine has access to data that the
client
should not, and would not, be able to share as freely as /they/ wish.
(Crash
dumps and similar, perhaps -- they might contain data that neither party
would
wish to see splashed around ?)

DRM http://en.wikipedia.org/wiki/Digital_rights_management

The client is paying $5 per month (or whatever) to listen to the latest
pop music. But the client is only allowed to listen to the music data using
your client. The client has no direct access to the music data, and the
client is not allowed to e-mail a copy of the music data to his/her friends.
Similarly for music videos, movies, video games, e-books, etc.

- Oliver

 

[Stefan Ram]

But the client is only allowed to listen to the music data using your client.

The first occurence of the word "client" in the above sentence
has another meaning than the final occurence of the wort
"client". The first occurence might be replaced by "customer" or so.

 

[Oliver Wong]

The first occurence of the word "client" in the above sentence
has another meaning than the final occurence of the wort
"client". The first occurence might be replaced by "customer" or so.

Yes, sorry for the confusion. Here's the same paragraph with the term
"Alice" and "your client" used in the proper locations.

Alice is paying $5 per month (or whatever) to listen to the latest pop
music. But Alice is only allowed to listen to the music data using your
client. Alice has no direct access to the music data, and Alice is not
allowed to e-mail a copy of the music data to her friends. Similarly for
music videos, movies, video games, e-books, etc.

- Oliver

 

[Chris Smith]

I'm finding it very difficult to imagine a scenario where this would be a
problem (assuming that client-side execution is OK in the first place, of
course).

I don't know. But upon re-reading the OP, the requirement was clearly
stated.

But then, I'm also having difficulty imagining a (legitimate) scenario where an
application running on a client's machine has access to data that the client
should not, and would not, be able to share as freely as /they/ wish. (Crash
dumps and similar, perhaps -- they might contain data that neither party would
wish to see splashed around ?)

You're having trouble imagining this in principle? Or you think it's
poor security to attempt it? I agree with the latter, but the former is
actually rather simple.

Let's hypothesize that I'm writing a gambling program. It's almost
certainly true that there are some bits of information that the user is
allowed to see, and some bits that the user is not allowed to see.
Furthermore, there is a fairly complex set of rules and conditions under
which information is constantly transitioning from secret to known, in
return for which the user has made certain committed actions.

Of course, actually implementing this as a client-side application would
only be reasonable if the degree of security required is lower than the
effort needed to cheat... which is why practically all gambling web
sites are web apps, and the remainder are client-server applications.
You'll never see a gambling site in which you play by downloading and
playing games completely offline and then uploading the results. That
doesn't mean the requirement is false; rather, it means that the
security is lacking.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

[me:]
But then, I'm also having difficulty imagining a (legitimate) scenario
where an
application running on a client's machine has access to data that the
client
should not, and would not, be able to share as freely as /they/ wish.
(Crash
dumps and similar, perhaps -- they might contain data that neither party
would
wish to see splashed around ?)

DRM [...]

Yes that would cover the case as I described it, but not the case that I was
actually meaning ;-) There there is the additional constraint that the client
will (or must) upload the data to my server rather than the other way around.

Still, possibly a variation on that idea is plausible. If I am in the business
of sellling (say) DRMed music for downlaod by other people (who are in a sense
customers of both myself and the actual artists). And if my part of the deal
is two-fold -- I provide a distrubution service for the artists (in return for
a cut of the sales), /and/ I provide recording/packaging/editing software for
the musicians to use that I feel is good enough to be be worth real money to an
artist who was using a different distributer (but am providing it at cur-price
to my "own" artists); then I would have an incentive to lock the cut-price
version of my software to my own distribution service.

-- chris

 

[Oliver Wong]

Still, possibly a variation on that idea is plausible. If I am in the
business
of sellling (say) DRMed music for downlaod by other people (who are in a
sense
customers of both myself and the actual artists). And if my part of the
deal
is two-fold -- I provide a distrubution service for the artists (in return
for
a cut of the sales), /and/ I provide recording/packaging/editing software
for
the musicians to use that I feel is good enough to be be worth real money
to an
artist who was using a different distributer (but am providing it at
cur-price
to my "own" artists); then I would have an incentive to lock the cut-price
version of my software to my own distribution service.

Yes, although for music it seems not too realistic. Here's the same idea
applied to videogames:

Distribute software, not for creating music, but for creating simple
games. Bundle along assets (e.g. 3D models, 2D sprites, music, sound
effects, etc.). Almost every kid who has played around with a computer has
dreamed of making their own computer game. Make their dream a reality by
giving out this software for free, and letting them design games to be
uploaded to your centralized server, and you then let others download and
play the game for a small fee. You take a cut of the fee, and send the rest
to the person who created the game.

You'd want to restrict the games created by your software to only be
playable from your distribution service because of the licensing terms of
the assets. (i.e. you probably had to hire artists and musicians
specifically for this project, and you so you don't want to just give away
their creative artwork for use in games if you're not gonna make a profit
from those games).

- Oliver

 

[Roedy Green]

The client is paying $5 per month (or whatever) to listen to the latest
pop music. But the client is only allowed to listen to the music data using
your client. The client has no direct access to the music data, and the
client is not allowed to e-mail a copy of the music data to his/her friends.
Similarly for music videos, movies, video games, e-books, etc.

The key there is to keep changing the client code and its encryption.
Then hackers have a moving target. see
http://mindprod.com/jgloss/obfuscator.html for tips on psychological
warfare against those who would defang your client.

Never leave plaintext on disk, even in a temporary file. If ram is a
problem, consider a task that decrypts and leaves behind a chunk
mildly encrypted e.g. xor with some pseudorandom pattern that you can
rapidly convert back to plaintext. You would staledate your
downloads so the freshness date is embedded in them. Your own player
would refuse to play them after a certain amount of time unless the
licence were renewed.

If feasible, require a new key every time the song is played. You
destroy the file as you go, so it will only work with a new
yet-unrevealed key.

At some point the song gets turned to analog. There is no way you can
stop recording of that signal.

 

[Roedy Green]

You'd want to restrict the games created by your software to only be
playable from your distribution service because of the licensing terms of
the assets. (i.e. you probably had to hire artists and musicians
specifically for this project, and you so you don't want to just give away
their creative artwork for use in games if you're not gonna make a profit
from those games).

that is a much harder problem. First a hacker can totally ignore your
upload program and go straight for the raw data files.
He has the code that made them. So he can decipher their format.

Your main defense is to keep changing the file format and sending out
compulsory JAWS updates that rearrange the files. Only the latest
version of the client software is permitted to talk to your server.

Your legit end users need have no awareness this is happening.

If hackers get to be a problem, your software can start doing sanity
checks, verifying the byte code with the server doing random "drug"
tests. the hackers have counter measures, but if you keep changing
things just a little bit, you can keep breaking their code and wear
them down psychologically.