Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Clarification

Reply
Thread Tools

Clarification

 
 
Ravi Shankar
Guest
Posts: n/a
 
      09-20-2005
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


 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      09-20-2005
Ravi Shankar wrote:

> 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


 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Karl_=D8ie?=
Guest
Posts: n/a
 
      09-20-2005
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


Ravi Shankar wrote:

> 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
>
>

 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      09-20-2005
"Ravi Shankar" <(E-Mail Removed)> wrote in message
news:dgp48l$4k9$(E-Mail Removed)...
> 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


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-20-2005
On Tue, 20 Sep 2005 21:53:25 +0800, "Ravi Shankar"
<(E-Mail Removed)> wrote or quoted :

>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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
Wibble
Guest
Posts: n/a
 
      09-20-2005
Roedy Green wrote:
> On Tue, 20 Sep 2005 21:53:25 +0800, "Ravi Shankar"
> <(E-Mail Removed)> wrote or quoted :
>
>
>>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.

It sounds like you may need a legal solution, not a technical one.
 
Reply With Quote
 
Ravi Shankar
Guest
Posts: n/a
 
      09-21-2005
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

"Roedy Green" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 20 Sep 2005 21:53:25 +0800, "Ravi Shankar"
> <(E-Mail Removed)> wrote or quoted :
>
>>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.
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Again taking new Java programming contracts.



 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      09-22-2005
Ravi Shankar <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
Oliver Wong
Guest
Posts: n/a
 
      09-22-2005

"Chris Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed).. .
> Ravi Shankar <(E-Mail Removed)> wrote:
>> 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?


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


 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      09-22-2005
Oliver Wong <(E-Mail Removed)> wrote:
> > 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.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Clarification Term: "Behavioural Description" Nikos Mitas VHDL 2 09-27-2005 05:36 AM
Pix error message clarification needed. Mike Cisco 0 04-18-2005 04:04 PM
Clarification on DR,BDR selection srini Cisco 1 02-12-2005 04:31 AM
clarification =?Utf-8?B?c3JpbmF0aGU=?= Microsoft Certification 0 05-22-2004 11:06 AM
Cisco PIX authentication proxy clarification lombardi Cisco 3 04-03-2004 11:13 PM



Advertisments