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:
- 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) - 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”
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.