On Wed December 24 2008, Edward Diener wrote: > Michael S. Zick wrote: > > On Wed December 24 2008, Edward Diener wrote: > >> In a client application communicating with a MySQL server, I am using > >> SSL to encrypt/decrypt data sent to and from the database. This requires > >> me to have the PEMs for the CA, client key, and client certificate > >> distributed as part of the application. Of course these certificates > >> will not work except with the corresponding server certificates on the > >> MySQL server to which I am communicating. > >> > >> My initial choice was to distribute the client certificates in the same > >> directory as the application's modules, as they are easy to find at > >> run-time there in order to make my SSL connection with the database. It > >> has been suggested to me that this is inherently insecure. Nonetheless I > >> must distribute them somewhere since the certificates have to exist in > >> the file system when I make the call at run-time to create a SSL > >> connection to the server. > >> > >> What are the best strategies to distribute these client certificates on > >> the end-user's machine ? Should I be pre-encrypting these certificates, > >> then decrypting them in memory before writing them to a temporary > >> location, and then destroying the decrypted certificates from that > >> temporary location after the connection is made, or is this overkill and > >> a simpler/better way of distributing the client certificates as part of > >> my application is possible ? > >> > >> Any suggestions, help, pointers would be much appreciated. > >> > > > > It is a hard question to answer without some knowledge of your risk model. > > What are the risks that you are trying to minimize? > > > > What harm is done if the files are accessable to the people who already > > have your application? Is this even a concern? Should it be? > > I am working for an employer who will be selling a product to end users. > The risk model is that my employer feels it would be bad if a hacker > were able to easily understand where the client certs reside in the end > user application and were able to use the client certs to communicate to > the server, ie. if someone who buys the product were able to use the > client certs in a destructive way. My employer has also been told by a > Sun representative he knows that if the client certs are distributed in > the directory of the application it is a serious security risk. So he > has asked me to investigate alternative ways of distributing the client > certs. > > My own feeling is that even with the client certs, nothing can be done > unless the host-server/username/password/database were known to > destructive hacker. > > But my employer is concerned and wants to make it more difficult for the > end users to be able to ascertain where the client certs are once they > install the application. >
Ah, so - Your risk model is: "Give the boss a warm and fuzzy feeling." The suggestion of using the ACL protection, to protect from casual or accidental access sounds like a good one - if your platform supports it. Use some light-weight, passphrase keyed, encryption to hide the contents. Consider using the "__from_memory" rather than the "__from_file" functions of openSSL so you don't have to write the "un-hidden" files back to the file system. For the passphrase, use a simple little linear-feedback-shift register to select bytes from some part of the application. That way the passphrase isn't stored as a string in the application, that part of the application would have to be reverse-engineered. Or maybe checksum (crypto hash function, that is) a critical dll for the passphrase. Should be hard to find among all the other sha256sum and such like calls in the application. This will not keep a cryptographer out of your application, but should pass the "warm and fuzzy" test. Mike > > > > Mike > >> Finally the client application runs on Windows and not LInux so if there > >> are OS specific arguments as to how to distribute these client > >> certificates you will know to what OS the application is targeted. > >> > >> Thanks ! > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
