Rajesh,
The scheme you are discussing is very similar to what Cisco does with a
lot of their network monitoring code. Cisco used the actual software and
not the install. This is probably a better option, given that the install
can also be tampered with or possibly reverse engineered and rewritten.
However, there are some caveats. First, this requires the machine have some
unique id. There are a couple of option there, but the most popular is Mac
address. Some Cisco software uses IP address, but this is prone to
difficulties given that the IP address of a given machine is subject to
change. Second, this scheme requires a server to do authentication. You
need to have some server authenticate or else it is possible to break.
So the bottom line is, any software you install on a users machine is
theoretically something that the user could get at and change. The only way
around this is to have a client and server architecture, and have the actual
logic of the application on the server. However, in real life the chances
of someone wanting to do this are pretty slim. Consider it similar to a car
alarm. They don't make your car impenetrable to thieves, but they do make
your car more difficult to steal.
Zack
-----Original Message-----
From: Rajesh Nair [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 19, 2000 4:22 PM
To: Gayathri Viswanathan; 'Zack Grossbart'; Gayathri Viswanathan;
[EMAIL PROTECTED]
Subject: RE: Java security question
This would require a self-coded lock or something, I presume. It's always
good to have obfuscation on the java class code. Like Zack mentions once
its in somebody's hands, they could make changes.
If obfuscation is really as good as it sounds, wouldn't it be possible to
limit the applet that has been installed once to make sure it cannot be
copied onto another location? I mean, say your applet has been
been installed on machine A. The applet is signed and has access to
installed m/c. Applet during installation,
creates a lock that identifies this machine uniquely. Person P is able to
make a small change say to logo
and sells it to Party Q. Party Q runs applet install. Install knows it's
being dumped on another m/c. Install
spews scary legalise at Q and fails to install?
If the applet is being used like normal applets, it would have access to m/c
that is serving it, right?
Does this sound even remotely fair to do?
At 02:05 PM 04/19/2000 -0400, Gayathri Viswanathan wrote:
>Zack,
>
>I have already signed my Java applet with a certificate from Thawte. But I
>thought that
>this means that Thawte certifies that noone has changed the jar file. But
>what if after
>accepting the certificate, some malicious user wishes to change the
contents
>of the jar file
>by say changing some image files (used for displaying logo) and then
signing
>it again and then
>selling it ? Would obfuscation help in this ? Can obfuscation be used on
>applets ?
>Is there any other alternative ?
>
>Thanks.
>
>-- Gayathri
>
>-----Original Message-----
>From: Zack Grossbart [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, April 19, 2000 1:30 PM
>To: Gayathri Viswanathan; [EMAIL PROTECTED]
>Subject: RE: Java security question
>
>
>Gayathri,
>
> Obfuscation would help prevent someone from decompiling and
>understanding
>your code, but not from changing it. You should sign your JAR file. Tools
>like Visual Cafe have this capability built in, or you can write a small
>utility to do it yourself using the javax.cript package. If you look on
the
>JavaSoft site you can get more data about signing JARs.
>
>Zack
>
>
>> -----Original Message-----
>> From: Gayathri Viswanathan [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, April 19, 2000 12:41 PM
>> To: [EMAIL PROTECTED]
>> Subject: Java security question
>>
>>
>> Hi !
>>
>> I have written a Java applet and we wish to make it into a product. I
have
>> the applet setup so that all the
>> resources that it needs are within a jar file. How can I make sure that
>> other people to whom we may sell the
>> software will not be able to disassemble the code or change some of the
>> image files or property files ?
>> Is obfuscation the way to go ? Can anyone help me ?
>>
>> Thanks a lot.
>>
>> -- Gayathri
>>
>>
>> ----------------------------------------------------------------------
>> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>>
>
>
>----------------------------------------------------------------------
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
Rajesh Nair
[EMAIL PROTECTED]
Ph: 913 599 7201
R&D
Informix Software
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
