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 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).
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 ! 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. Please suggest & let me know if you need any other information from my side. Cheers ! On Tue, Sep 16, 2008 at 1:29 AM, David Schwartz <[EMAIL PROTECTED]>wrote: > > > As per the current mechanism PEM file needs to be the part > > of the client bundle, but that is not good for the safety > > of the client's private key (as this way key file will be > > visible to all the users of the application). > > This private key identifies someone who is a user of the application. So > why > shouldn't it be visible to all the users of the application? > > > I am looking for some mechanism to directly hardcode the > > key in the code & directly read it from there. > > That would mean that anyone with access to the code would be entitled to > the > private key. Yet these seem to be the same people you are trying to keep > the > key from. > > > Can anyone give me some idea on this. What format I can > > use to specify the PEM data in the code & what APIs can > > be used to read the private key directly from the memory buffer. > > In order to distinguish people authorized to use the private key from what > exactly? > > You need to explain your threat model. > > If you're trying to stop people from giving your software, and thus the > private key, away, you need to use some kind of hardware-based lock. If you > want to stop the same people from accessing the same resource two different > ways, you need some kind of obscurity. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
