Java security  
Author Message
yvashchenko





PostPosted: 2004-9-29 18:48:00 Top

java-programmer, Java security I havean applet that connects to Oracle osing the thin client. It
works when run from IDE. When I try to load it into a web browser I
get

java.security.AccessControlException: access denied
(java.util.PropertyPermission oracle.jserver.version read)

What's up?
 
Robert Klemme





PostPosted: 2004-9-29 22:58:00 Top

java-programmer >> Java security
"yvashchenko" <email***@***.com> schrieb im Newsbeitrag
news:email***@***.com...
> I havean applet that connects to Oracle osing the thin client. It
> works when run from IDE. When I try to load it into a web browser I
> get
>
> java.security.AccessControlException: access denied
> (java.util.PropertyPermission oracle.jserver.version read)

Applets are only allowed to contact the server they originated from unless
they are signed. It's generally not a good idea to write an applet that
uses JDBC directly. Rather communicate with the server and have him do
the DB work. You can make your life easier by using serialized data for
the communication. That way the parsing is done for you.

robert

 
yvashchenko





PostPosted: 2004-9-30 17:19:00 Top

java-programmer >> Java security Robert
Danke shoen,

But could you explain the fact that I can run the very same applet
from IDE (IntelligIdea)? Apparently it means that this is possible
somehow.

The problem is that I do not have access to the server and I need this
application to be a part of a webpage.


Yuri

"Robert Klemme" <email***@***.com> wrote in message news:<email***@***.com>...
> "yvashchenko" <email***@***.com> schrieb im Newsbeitrag
> news:email***@***.com...
> > I havean applet that connects to Oracle osing the thin client. It
> > works when run from IDE. When I try to load it into a web browser I
> > get
> >
> > java.security.AccessControlException: access denied
> > (java.util.PropertyPermission oracle.jserver.version read)
>
> Applets are only allowed to contact the server they originated from unless
> they are signed. It's generally not a good idea to write an applet that
> uses JDBC directly. Rather communicate with the server and have him do
> the DB work. You can make your life easier by using serialized data for
> the communication. That way the parsing is done for you.
>
> robert
 
 
Robert Klemme





PostPosted: 2004-9-30 18:05:00 Top

java-programmer >> Java security
"yvashchenko" <email***@***.com> schrieb im Newsbeitrag
news:email***@***.com...
> Robert
> Danke shoen,
>
> But could you explain the fact that I can run the very same applet
> from IDE (IntelligIdea)? Apparently it means that this is possible
> somehow.

Apparently the IDE does not employ a SecurityManager. There is no server
that the applet was loaded from so it can't possibly check the connection.
Well it could use localhost, but apparently there are no checks.

> The problem is that I do not have access to the server and I need this
> application to be a part of a webpage.

As I said: don't use JDBC in applets. In your case either implement your
own protocol over HTTP or use Java WebStart.

robert

>
>
> Yuri
>
> "Robert Klemme" <email***@***.com> wrote in message
news:<email***@***.com>...
> > "yvashchenko" <email***@***.com> schrieb im Newsbeitrag
> > news:email***@***.com...
> > > I havean applet that connects to Oracle osing the thin client. It
> > > works when run from IDE. When I try to load it into a web browser I
> > > get
> > >
> > > java.security.AccessControlException: access denied
> > > (java.util.PropertyPermission oracle.jserver.version read)
> >
> > Applets are only allowed to contact the server they originated from
unless
> > they are signed. It's generally not a good idea to write an applet
that
> > uses JDBC directly. Rather communicate with the server and have him
do
> > the DB work. You can make your life easier by using serialized data
for
> > the communication. That way the parsing is done for you.
> >
> > robert

 
 
james





PostPosted: 2005-3-28 21:01:00 Top

java-programmer >> Java security Hi all,

My company is trying to decide make a platform desicion between
C++/Java. I am in favor of Java however I am compelled to answer a
question yet I am unable to find a solution.

The problem is as follows: The application will have a two secret keys
(A 128 bit constants) and a public encryption algorihtm (AES). It will
encrypt some data offline and send via public methods to some other
place at a later time(not our server). Obviously, the security of this
data is extremely important. (A financial application). Application
will only be provided to trusted entities therefore I don't have to go
thru authentication. (ie. verify the sender)

Our concern is one could decompile the Java class files and see what
these constants are and hence break the whole system. I have checked
out various solutions to see how can we avoid this issue and not yet
come up with a 100% secure solution.

Obsfucation doesn't work as it doesn't really hide the constants.

Encyrption of the constants: If we did this, someone can enrypt these
constantants. This solution is nothing more than adding another layer
to the difficulty. (We can pick a private algorithm but decompiling
would expose algorithm)

I also can not change the JVM to add extensions as I would have to
deploy multiple extensions for various platforms.

I appreciate any pointers.

Thanks,
James
 
 
Michael Amling





PostPosted: 2005-3-28 22:25:00 Top

java-programmer >> Java security James wrote:
> Hi all,
>
> My company is trying to decide make a platform desicion between
> C++/Java. I am in favor of Java however I am compelled to answer a
> question yet I am unable to find a solution.
>
> The problem is as follows: The application will have a two secret keys
> (A 128 bit constants) and a public encryption algorihtm (AES). It will
> encrypt some data offline and send via public methods to some other
> place at a later time(not our server). Obviously, the security of this
> data is extremely important. (A financial application). Application
> will only be provided to trusted entities therefore I don't have to go
> thru authentication. (ie. verify the sender)
>
> Our concern is one could decompile the Java class files and see what
> these constants are and hence break the whole system. I have checked
> out various solutions to see how can we avoid this issue and not yet
> come up with a 100% secure solution.
>
> Obsfucation doesn't work as it doesn't really hide the constants.
>
> Encyrption of the constants: If we did this, someone can enrypt these
> constantants. This solution is nothing more than adding another layer
> to the difficulty. (We can pick a private algorithm but decompiling
> would expose algorithm)

This is a classic problem. How could C++ solve it any better than Java?

Have you considered public key cryptography? A program need not be
capable of hiding a secret to send data confidentially to a recipient
with a known public key. Basically, Alice knows Bob's public key. Alice
encrypts the data with a secret key selected at random at runtime. Alice
sends the random secret key, encrypted with Bob's public key, along with
the ciphertext. Bob can recover the random secret key using the private
key that corresponds to his public key and with the random secret key in
hand, can decrypt the ciphertext.

--Mike Amling
 
 
Oscar kind





PostPosted: 2005-3-28 23:37:00 Top

java-programmer >> Java security In comp.lang.java.help James <email***@***.com> wrote:

[cut: the need for keeping data of a financial application secret]

> Our concern is one could decompile the Java class files and see what
> these constants are and hence break the whole system. I have checked
> out various solutions to see how can we avoid this issue and not yet
> come up with a 100% secure solution.
>
> Obsfucation doesn't work as it doesn't really hide the constants.

Yes it does, provided you use the right obfuscation. Flow obfuscation
doesn't really help here, as the algorithm is known. String obfuscation
however, mangles the constants (base64 encoded for example). This is
probably even more difficult to decompile than compiled C/C++ code, as
constants are also easily decompilable for those languages.


> Encyrption of the constants: If we did this, someone can enrypt these
> constantants. This solution is nothing more than adding another layer
> to the difficulty. (We can pick a private algorithm but decompiling
> would expose algorithm)
>
> I also can not change the JVM to add extensions as I would have to
> deploy multiple extensions for various platforms.

This provides the clue that obfuscation doesn't work. It also shows why
C/C++ in themselves are not a solution either: reverse engineering is
always possible (you can only make it more difficult).

The suggestion of another poster to use an asymetric algorithm is much
better, as the means of decompiling are not available then.


--
Oscar Kind http://home.hccnet.nl/okind/
Software Developer for contact information, see website

PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
 
 
Michel Gallant





PostPosted: 2005-3-28 23:42:00 Top

java-programmer >> Java security "Michael Amling" <email***@***.com> wrote in message news:ntU1e.18737$email***@***.com...
> James wrote:
> > Hi all,
> >
> > My company is trying to decide make a platform desicion between
> > C++/Java. I am in favor of Java however I am compelled to answer a
> > question yet I am unable to find a solution.
> >
> > The problem is as follows: The application will have a two secret keys
> > (A 128 bit constants) and a public encryption algorihtm (AES). It will
> > encrypt some data offline and send via public methods to some other
> > place at a later time(not our server). Obviously, the security of this
> > data is extremely important. (A financial application). Application
> > will only be provided to trusted entities therefore I don't have to go
> > thru authentication. (ie. verify the sender)
> >
> > Our concern is one could decompile the Java class files and see what
> > these constants are and hence break the whole system. I have checked
> > out various solutions to see how can we avoid this issue and not yet
> > come up with a 100% secure solution.
> >
> > Obsfucation doesn't work as it doesn't really hide the constants.
> >
> > Encyrption of the constants: If we did this, someone can enrypt these
> > constantants. This solution is nothing more than adding another layer
> > to the difficulty. (We can pick a private algorithm but decompiling
> > would expose algorithm)
>
> This is a classic problem. How could C++ solve it any better than Java?
>
> Have you considered public key cryptography? A program need not be
> capable of hiding a secret to send data confidentially to a recipient
> with a known public key. Basically, Alice knows Bob's public key. Alice
> encrypts the data with a secret key selected at random at runtime. Alice
> sends the random secret key, encrypted with Bob's public key, along with
> the ciphertext. Bob can recover the random secret key using the private
> key that corresponds to his public key and with the random secret key in
> hand, can decrypt the ciphertext.
>
> --Mike Amling

This concept of generating a random symmetric key for bulk encryption,
and encrypting that secret symmetric key with the public key of recipient(s)
is called "enveloping".
A pkcs standard called EnvelopedData encapsulates the various bits (symmetric
encrypted blob, RSA-encrypted symmetric key and recipient certificate .. etc..).
EnvelopedData structures are further encapsulated into common secure email
S/MIME formats, which makes sending encrypted files (granted with size limitations by email
attachment restrictions) really simple.
Currently Java does not support these encapsulations so you need to use 3rd
party support. e.g. here is Bouncy Castle sample:
http://www.jensign.com/JavaScience/javacrypto
or of course, you can roll your own custom format (which can expose other security
problems!)

- Mitch Gallant
www.jensign.com


 
 
Robert Angelino





PostPosted: 2005-3-29 0:49:00 Top

java-programmer >> Java security Michael Amling wrote:
> James wrote:
>
>> Hi all,
>>
>> My company is trying to decide make a platform desicion between
>> C++/Java. I am in favor of Java however I am compelled to answer a
>> question yet I am unable to find a solution.
>>
>> The problem is as follows: The application will have a two secret keys
>> (A 128 bit constants) and a public encryption algorihtm (AES). It will
>> encrypt some data offline and send via public methods to some other
>> place at a later time(not our server). Obviously, the security of this
>> data is extremely important. (A financial application). Application
>> will only be provided to trusted entities therefore I don't have to go
>> thru authentication. (ie. verify the sender)
>>
>> Our concern is one could decompile the Java class files and see what
>> these constants are and hence break the whole system. I have checked
>> out various solutions to see how can we avoid this issue and not yet
>> come up with a 100% secure solution.
>>
>> Obsfucation doesn't work as it doesn't really hide the constants.
>> Encyrption of the constants: If we did this, someone can enrypt these
>> constantants. This solution is nothing more than adding another layer
>> to the difficulty. (We can pick a private algorithm but decompiling
>> would expose algorithm)
>
>
> This is a classic problem. How could C++ solve it any better than Java?

This is a classic question software designers face---especially when
secure applications are involved. If anyone who thinks their software,
even an executable, is "secure"--they are fooling themselves. I can
just as easily dissemble a native exe and get assembly as I can
construct the
java source from a jar file. All you're doing is slowing someone down.
However, Java is by far the easiest to reassemble to something that
looks amazing close to the original source. Yes, Java provides
such an easy platform for development, yet nothing comes for free.
Shipping a java exe is way better than shipping a jar file. The
way to protect yourself is through copyrights, embedded algorithms
that make your software detectable in case someone is trying to
duplicate your functionality and is too lazy to change it enough to hide
his efforts, and dare I say it without starting a debate on free
software----patents. This is just the software, placing constants or
encryption keys in source is just not smart. Design your software such
that your keys reside on usb-based keys fabs so that you can change them
often. Keep in mind no matter how you design this aspect of your
application, there will always be a way of breaking it, all you're
doing is slowing someone down.....

<snip>

-robert
 
 
Pat Farrell





PostPosted: 2005-3-29 14:18:00 Top

java-programmer >> Java security James wrote:
> Our concern is one could decompile the Java class files and see what
> these constants are and hence break the whole system. I have checked
> out various solutions to see how can we avoid this issue and not yet
> come up with a 100% secure solution.

No serious security system can rely upon hiding the secrets.
It is at best, Security By Obscurity.

You have to assume that people will disassemble, decompile, etc.
the code you distribute. It has nothing to do with the language
chosen.

You can not have a 100% secure system without having either a human
enter a key periodically, or using a hardware crypto box. Since the
hardware crypto boxes cost thousands of dollars, it is probably
unrealistic.

You have to weigh security against convience for your users.
As you get more secure, you will have hassled users. Get used to it.

A more important question to ask yourself is "how valuable is the thing
I'm trying to protect". It is is low value, like the MP3 bits of a song,
you know what is the appropriate security to apply.




--
Pat Farrell email***@***.com
PRC Recording http://www.pfarrell.com/prc/
 
 
KiLVaiDeN





PostPosted: 2005-3-29 14:27:00 Top

java-programmer >> Java security
"James" <email***@***.com> a 閏rit dans le message de
news:email***@***.com...
> Hi all,
>
> My company is trying to decide make a platform desicion between
> C++/Java. I am in favor of Java however I am compelled to answer a
> question yet I am unable to find a solution.
>
> The problem is as follows: The application will have a two secret keys
> (A 128 bit constants) and a public encryption algorihtm (AES). It will
> encrypt some data offline and send via public methods to some other
> place at a later time(not our server). Obviously, the security of this
> data is extremely important. (A financial application). Application
> will only be provided to trusted entities therefore I don't have to go
> thru authentication. (ie. verify the sender)
>
> Our concern is one could decompile the Java class files and see what
> these constants are and hence break the whole system. I have checked
> out various solutions to see how can we avoid this issue and not yet
> come up with a 100% secure solution.
>
> Obsfucation doesn't work as it doesn't really hide the constants.
>
> Encyrption of the constants: If we did this, someone can enrypt these
> constantants. This solution is nothing more than adding another layer
> to the difficulty. (We can pick a private algorithm but decompiling
> would expose algorithm)
>
> I also can not change the JVM to add extensions as I would have to
> deploy multiple extensions for various platforms.
>
> I appreciate any pointers.
>
> Thanks,
> James

Never give encrypt keys on an application.
You can make your application gather encrypted data from network, but find
another solution to provide the keys to decrypt it. I'd suggest emails, but
they are not really secure (if you are paranoid about security), so better
give them by phone or letter, or use a SSL http website with the user login,
that'll show him "his" decrypt key, and not everybody's key. I am not sure,
but I think you already planned that, just pointing it, because in my
opinion, it's the biggest flow to give keys in your application (even if
they are encrypted), as then potential "hackers" would have all datas they
need single packaged.

Now that said, concerning the algorithm for decryption, I'd say that no
matter what you do, there is always a way to reverse engineer the class
files ( or the exe files ). However, it has been clear that class files can
be much easily interpreted than native source code, as there is tools that
allow you to check the java code, tools which are very much harder to find
concerning native code ( you'll be able to disassemble code, but assembly is
completely another thing than Java ). This said, I'd suggest that once
again, you make your data go through a SSL connection, and gather all the
data you need with xml or something like that.. Got no real idea how to
implement that the best way, but I think SSL is the real thing you need for
your application, even though i'm unsure wether it's possible to send a file
with SSL encryption.. But the idea is to have algorithms at home, and only
allow trusted users to use the online objects.

K