 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Security / April 2004hackproof applets
Hi, I've read that if I'd want to check if someone has tampered with my applet, I'd have to use a message diggest or a digital signature to check if it's the original one. But how would this be implemented? Is it something that the JVM does for you? Because else, you could still decompile and "fake" the signature... I also found that cached applets have somekind of checksum added to them, thats why I thought the JVM has an build-in mechanism that does this for you? Thanks, Thijs >I've read that if I'd want to check if someone has tampered with my applet, >I'd have to use a message diggest or a digital signature to check if it's >the original one. See http://mindprod.com/jgloss/digitalsignature.html You digitally sign your applet with a REAL certificate, not a self-signed phony one. see http://mindprod.com/jgloss/certificate.html Then no one can then modify the file in any way and still make it look as if it were signed by you. They could make one that looked is if it were SELF-signed by you or signed by someone else. But they could not make it look like Thawte vouched that you wrote it and it was untampered with. That is all you have to do. The browser automatically verifies the signature if one is present. This of course does nothing to stop a pirate from decompiling your Applet. You give him the class files on a plate (actually in a jar) which are very easy to decompile. See http://mindprod.com/jgloss/obfuscator.html http://mindprod.com/jgloss/decompiler.html -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >>I've read that if I'd want to check if someone has tampered with my >>applet, I'd have to use a message diggest or a digital signature to check [quoted text clipped - 6 lines] > > see http://mindprod.com/jgloss/certificate.html Hm, 404 on that one. > Then no one can then modify the file in any way and still make it look > as if it were signed by you. They could make one that looked is if it [quoted text clipped - 4 lines] > That is all you have to do. The browser automatically verifies the > signature if one is present. Sure, but how does the server know that the applet has not been tampered with? I think that was OP's concern. IMO this is very difficult to do: most methods you can come up with can be easily circumvented by keeping an unmodified copy of the original applet around and forwarding all authentication-related traffic to it. Any client-server application that relies for its security on the integrity of the client is living dangerously. Matthijs, at the practical level you might consider looking at Roedy's "Obfuscation" page and see what technical or psychological means you can adapt to your situation. (Obfuscation in itself isn't a solution, because the attacker could reverse-engineer the applet by studying what happens on the wire. It's more a question of how to destabilise your opponent's brain). Good luck,  SignatureChris Gray chris@kiffer.eunet.be /k/ Embedded Java Solutions Try http://www.mindprod.com/jgloss/digitalsignatures.html (An 's' was missing) >>>I've read that if I'd want to check if someone has tampered with my >>>applet, I'd have to use a message diggest or a digital signature to check [quoted text clipped - 34 lines] > > Good luck, >>>I've read that if I'd want to check if someone has tampered with my >>>applet, I'd have to use a message diggest or a digital signature to check >>>if it's the original one. >> >> See http://mindprod.com/jgloss/digitalsignature.html oops try http://mindprod.com/jgloss/digitalsignatures.html -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. Exactly, this subject is a bit hazy for me... Most security applications focus on identifying the authenticy of the server. I want to make sure that the client sends me back legitimate information (through the original applet). What I've come to understand from all this is that: 1.) SSL mainly ensures information send can't be tapped by a man in the middle, the sender/receiver still is able to see what he sends/receives with a web proxy and where it's send to, so he could just send his own info along to that adress. 2.) Digital signatures can ensure the client that the applet is the original one created by me. 3.) Obfuscation is nice to make it more difficult for a hacker, but I'd certainly should never rely on only obfuscation I think for my situation there should be some method by which I can check if the information the client sends, is through the connection by which the applet was called... like client authentication by SSL or something? Im sure there must be somekind of scheme for this problem as I think it's a very common one. Imagine a game applet where the user sends back it's highscore to a server. You don't want the user to send his own score to the server, you wan't to make sure that this score is played and send in a legitimate way... Does anyone know how this is could be done? Thanks in advace! Matthijs Blaas "chris" <chris@kiffer.eunet.be> wrote in message > > > Sure, but how does the server know that the applet has not been tampered > with? I think that was OP's concern. [quoted text clipped - 12 lines] > > Good luck, > Exactly, this subject is a bit hazy for me... Most security applications > focus on identifying the authenticy of the server. I want to make sure that [quoted text clipped - 17 lines] > the information the client sends, is through the connection by which the > applet was called... It won't be from the same TCP connection. > like client authentication by SSL or something? Im sure > there must be somekind of scheme for this problem as I think it's a very > common one. Imagine a game applet where the user sends back it's highscore > to a server. You don't want the user to send his own score to the server, > you wan't to make sure that this score is played and send in a legitimate > way... Does anyone know how this is could be done? Nothing I can think of will be foolproof. Can you vary each copy of the applet sent? If so, while this is not foolproof, you could include a unique private key for each downloaded applet copy, and require that data returned by signed by the appropriate private key. (Or use a secret key and require a MAC.) --Mike Amling >> see http://mindprod.com/jgloss/certificate.html > >Hm, 404 on that one. That's odd. I just tried it and it worked for me. Try a ping on mindprod.com and see what IP you have. You should get 24.87.56.253 Maybe your DNS cache is out of date. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >. (Obfuscation in itself isn't a solution, because >the attacker could reverse-engineer the applet by studying what happens on >the wire. It's more a question of how to destabilise your opponent's brain). You have a huge advantage over hackers in a client server situation. Desktop software guys are sitting ducks. The hacker can take years if he wants to study, and they have way of monitoring what the hackers are up to. Further you keep your client software slim, so that most of the intelligence is in the server where the hacker never gets to see it. You can change ANYTHING at any time. The instant the hacker figures out something, you can make his knowledge obsolete. Further the hacker needs your server to test with. If he slips just once and you detect a hack, you can bar his IP. Now he needs a new IP to continue his experiments. The idea is not to stop him, just to make his life so frustrating the game is not worth the candle. In my essay on obfuscation, I talk about the ways of raising false hope in the hacker and then dashing it. The hacker then never knows for sure when he has finally succeeded. From a practical situation, if you do ANY sort of procedure, it will keep 99% of people out. You can work handle the other 1% by detection and barring, while you work on a heavy duty solution. It may be a waste of money to buy a bank vault lock for your log cabin in the woods. A simple system that should drive most hackers crazy would be to ten ten methods to do authentication. They each do something different and goofy. e.g. time * 42 time folded on itself low high byte with xor. ip % 149 Then you simply use a different algorithm each day. You have to update the jar file and the server. The hacker has to FRESHLY figure it out each day with manual effort. You might even use a program to generate goofy but syntactically correct code automatically each day. It would take a dedicated guy to figure out how to automatically freshly steal that class every day. You could make that even more annoying through obfuscation and changing the method's signature a bit with some junk parms. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. Mike Amling wrote: >Nothing I can think of will be foolproof. Can you vary each copy of >the applet sent? If so, while this is not foolproof, you could include a >unique private key for each downloaded applet copy, and require that >data returned by signed by the appropriate private key. Yeah if I could vary the key's hidden in each downloaded applet that would certainly be an acceptable solution... Only thing is I wouldn't know how to achieve that in an automatic fashion... I believe it's impossible to write my my own classloader for an applet because of security reasons... Maybe something is possible with java server pages? Is it even possible to have something burned (or added) into an already compiled applet? > Mike Amling wrote: > [quoted text clipped - 10 lines] > pages? Is it even possible to have something burned (or added) into an > already compiled applet? You could create and send a .jar file dynamically, containing the applet (along with an individualized key as a resource in the jar). Of course, none of the approaches discussed would prevent the end user from using the individualized key they receive to send forged messages signed with that key. >> Mike Amling wrote: >> [quoted text clipped - 19 lines] > the individualized key they receive to send forged messages signed with > that key. I was thinking of the server invoking jar -u to add a .class file to the .jar file just before sending it out, a .class that is updated at the last moment with a fresh private key. An Elliptic Curve Cryptography private key is just any string of bits of a chosen size, so you can generate one quite quickly, unlike RSA. A hexadecimal representation of the key can be substituted into a String literal in the .class file at the last minute. For instance, compile the class with the private key represented in hex as the String literal value "1C64409700FF3E82313A481E954AE4B39ADFEEE2", which will appear in the .class file as 20 consecutive bytes containing those ASCII digits. Replace those bytes in the .class file with some hexadecimal digits chosen at the last minute. There's no need to actually parse the .class file. It will contain exactly one occurrence of 1C64409700FF3E82313A481E954AE4B39ADFEEE2 and that's the one to replace. When the code runs on the user's system as part of the applet, the String literal it uses will be the substituted value. If the applet itself has to be signed, it gets a little tricky. --Mike Amling I had the idea of doing all this in php, since a jar is basicly a zip, I could just modify the jar from php (adding the key file into it). But at a practical level I don't want to do it this way; if the server needs thousands similtaneous operations like that, it will certainly bail out at some point. Also, when the game applet is obfuscated it will be a real pain to find the apropiate class file(s) :-) I came up with the following scheme: I have a loader applet (this is just one class file), this loader applet is modified by the server before downloading it, I "burn in" the private key in this loader applet. Server sided this is far less costly than performing operations on a jar, the loader applet then acts as a holder for the game applet, which then has access to the burnt in private key in the loader class. I believe this can be done by implementing the AppletStub interface? That way it can instantiate the main applet and add it as a child component itself... > Mike Amling wrote: > I was thinking of the server invoking jar -u to add a .class file to [quoted text clipped - 17 lines] > > --Mike Amling >I came up with the following scheme: >I have a loader applet (this is just one class file), this loader applet is [quoted text clipped - 5 lines] >That way it can instantiate the main applet and add it as a child component >itself... That sounds clumsy. Further, you can't sign such a thing. Let's try this again. What you want to know is are messages coming in from my untampered Applet. You want your applet to have a private key that can't easily be extracted by a hacker, since he has full access to your class files, just like legit users. Let us say you change this private key daily. All you really need to do now is make it difficult to extract the private key from a recent class file. You don't want him to easily create an automated private key grabber. Unless you hide the key in a different way every day and have no method that can be called to grab the assembled key (the kicker), I think the hacker has you. Here is another approach what I call the "millionaire" method. How does the applet prove he is really THE applet? You send him a challenge METHOD loaded dynamically via class.forName which does some computation -- to check that it is the real applet, exercise some method, compute a checksum of something -- anything you please. The Applet has to answer within say 4 seconds, or you cut him off. If he answers correctly, you let him stay on THAT SOCKET. But that is all. You do things like add the system time to your answer so that if the hacker tries to simply send the same answer back when he gets the same challenge, it won't work. He actually has to simulate the running of the challenge method, which can be timing dependent. You can ask about free memory or other things that would change if the Applet were tampered with. If hackers start cracking your challenges, you drop them and use more fiendish ones. This all totally independent of the jars. To frustrate them you can mix them up so they can't do repetitive tests to crack one of your challenges. This makes it somewhat harder for him to decompile your challengers. Further if you find an IP failing your challenges, you can blacklist that IP. You don't have to sit their passively. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. Yeah I agree with you. I thought of something similar too; imagine if you phone Bob over a crappy phone line, how can tell it's really Bob? You could agree with him upon a secret answer and if he answers correct keep talking to him via an agreed protocol. I could combine the two methods, a dynamical burnt in key in the applet loader(the secret answer) and a response timer of x seconds, if he doesn't response within x secs he won't be able to send anything to that socket ... it would be a good hacker if he'd be able to decompile, extract the burnt in key and response within fx 4 seconds... That would be the most secure situation. The problem with this is however that eshtablishing a socket connection may give problems with people behind proxies & firewalls? 8( That would certainly mean a lot of people won't be able to play my game... I did some research how other big online gaming websites do this, and I found out that most are pretty insecure! I was able to hack a few of them by just monitoring the html traffic with an web proxy and do my own posts to the receiving side. www.pogo.com (from EA) seems to be the most secure. It sends a public key as a parameter and use build in security algorithms (I think... I doubt they dynamically burn in key's). They also have their applets obfuscated. This itself is pretty secure, but looking at the prizes you could win it will certainly be an challenge to crack the algorithms they use... If the sockets method will cause problems with proxy users then I think it's still the best way to go with a buildin key or a burnt in key, some very complicated client sided logic and have it all obfuscated... Anyway thanks for thinking with me! -Thijs > You send him a challenge METHOD loaded dynamically via class.forName > which does some computation -- to check that it is the real applet, > exercise some method, compute a checksum of something -- anything you > please. The Applet has to answer within say 4 seconds, or you cut him > off. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.