views:

38

answers:

1

I have a java application that needs to connect to a server. Its rather simple to ensure that the server is not spoofed using SSL but I can't seem to wrap my head around on how the server would authenticate the client to ensure that the request is coming only from a trusted party. Only the first communication needs to be authenticated. During that communication step the client and the server will exchange some information that will be used to subsequently authenticate the client.

One approach I can think of is to digitally sign the application and then send the digital signature of the application to the server. The server verifies the digital signature to authenticate the client. Now I have a couple of questions regarding this:

  1. Is it possible to get the application's digital signature from within itself. If it is, then how? (I've tried searching for this on the internet but couldn't find any way to do so)
  2. Is it possible to extract this signature using other means such as a HEX editor. If this is known then anyone can just send that signature to the server and spoof the client.

Also, please let me know if I am totally on the wrong track here :)

EDIT: By "trusted party" i mean an "Unmodified client"

+3  A: 

Also, please let me know if I am totally on the wrong track here :)

You are :)

Your goal is to "ensure that the request is coming only from a trusted party" - if "trusted party" is interpreted as "trusted user", this is the standard authentication problem that millions of websites around the world solve daily via simple password authentication. If you want to get fancy (and inconvenient/expensive), you can use SSL client certificates or RSA tokens.

However, you seem to interpret "trusted party" as "trusted user using an unmodified client", where "unmodified" includes modifications done on purpose by the user.

Well, forget about that. Can't be done, unless you let the user only use physically secured hardware provided by you. It's simply not possible to protect software from being manipulated arbitrarily by someone controlling its execution environment. The movie industry has spend billions, forced new standards to be more complicated and expensive to implement due to encryption and license requirements, and alienated many of its customers trying to do that, and failed (repeatedly).

Edit: It seems like it's not even about the client at all (as in protecting it against modification, usually that means anti-piracy measures), it's apparently about controlling access to the server. In that case, stop wasting brain time thinking about the client. That's not your problem. Access to the server is. So start thinking about the protocol, how it authenticates clients and what requests it will accept. Fix your protocol so that "pretending to be the client" is a non-issue because requests other than those the legitimate client might send simply won't be accepted.

Michael Borgwardt
You are right, I am interpreting "trusted party" as an "Unmodified client". There's no human user for this case. What I am trying to avoid is someone de-compiling the application, understanding the logic on how to communicate with the server and then pretending to be the client. Shouldn't code signing be able to solve such a problem?
Prashast
@Prashast: nope, complete waste of time. You can make it more difficult via code obfuscation, but as I said, protecting software against a malicious user controlling its execution environment is not even theoretically possible. Also, see Edit.
Michael Borgwardt
@Michael Borgwardt: If my code is signed by my private key shouldn't I be able to check that digital signature somehow for authentication? Oh well, I'll have a lot of re-thinking to do if this cannot be done :)
Prashast
@Prashast: An attacker can simply remove the check if it's done in the client, and send a fake signature if it's done in the server.
Michael Borgwardt
Fair enough. Thanks for your help!
Prashast