Dan Ribe: > I am using the private key just to authenticate the client. > Once server has authenticated the client (by using the public > key of client), it will give access to that client.
So you want the server to condition access to a resource based on what software is being used, and to reject even people who *have* your software just because they're not *using* it? In other words, you don't want to separate people who can do X from people who can't do X. You want to separate people who can do X from other people who can do X based on what software they use to do X. Cryptography cannot do this. Over the wire, there is no way to tell what software you used to execute an algorithm, only what algorithm you executed. > So I will say that in this case users of my client application > need not to have access to the private key (becasue this > authentication process is kind of transparent to them). But they do need access to the private key, otherwise they can't perform the authentication. It's transparent to them, so they don't need to know they have access to the key, but they need it. Without access to the key, they can't participate in this process. > If I will place the private key in some file (in the app bundle), > then there are chances of its misuse. I mean someone can write a > client, can authenticate it using the key & can get access to the > server functionality, which it not desirable ! Someone who could do all that could just as well give copies of the client to the same undesirable agents. They could then authenticate using the key and can get access to the server functionality. To protect the server functionality from people who shouldn't be able to use it, you need to control who gets access, not what software they use. Any mechanism by which they could get a private key could also deliver them the whole client software package. > So what I am looking for is a way to specify the private key > directly on the code, so that is hidden from the outside world > & yet client is able to authenticate itself by using it. That would change nothing. If what you suggested was perfectly possibly, anyone could get access to the server functionality just by getting the client package. If you simply include the private key in the client package, then anyone can access the server functionality just by getting the client key. In both cases, precisely the same things safeguard the server. > Please suggest & let me know if you need any other information from my side. Cyptography can help you authorize one agent and not authorize another based on what the first agent knows or can do that the second cannot. But it really cannot do much to help you authorize and de-authorize the same agent based on what software or hardware it uses to perform an operation it knows how to perform. It sounds like you need dongles, not keys. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
