Hi Edward: Ok - I'm going to reply, but I'm also going to top post, since doing a point by point discussion isn't going to help.
The concept of Private/Public key cryptography (of which X.509 Certificates are one invocation), is that a single private key belongs to a single security principle. The security principle may have more than one private key, but a given private key is only attributable to a single security principle. Now, a security principle can be anything - a single person, a unique customer, a server, a space ship, an aeroplane, a ham sandwich (ok, maybe not the last :) But, the point is - what you are trying to do is to have a single private key associated with more than one customer - this breaks such a fundamental principle of private/public key cryptography that my colleagues on this list are having a difficult time expressing themselves :) In short - the right way to solve your problem is to have EACH customer have a unique set of credentials (such as a private/public key pair/certificate), and use that credential to authenticate themselves to the server, which, should, in turn, be also configured to only allow a given customer to only do what that customer SHOULD be allowed to do. To give all of your customers the same private key is working with a horrendously wrong security model, and offers nothing other than sprinkling magic crypto dust on your system in the hopes of making it secure (otherwise known as Security Theater). Each customer needs their own, unique private key and associated certificate, and they need to protect that private key according to whatever security model the environment you are working in requires (for instance, if you are working in a US Federal Class III environment, you probably need to have that private key on some form of hardware token). If you are working on the public internet, then you will have to do a proper threat analysis of the value and potential attackers that the data you are handling would attract. Have you done your threat tree yet??? I hope that I have helped you clear up any misconceptions - in short - what you are talking about doing - please don't - as others have said - that is a failed model of DRM, and you are only going to protect your system from those it doesn't need protecting from. Have fun. Patrick. Edward Diener wrote: > Michael S. Zick wrote: >> On Fri December 26 2008, Edward Diener wrote: >>> Kyle Hamilton wrote: >>>> If your company hires a security consultant, s/he will state the >>>> same thing. >>> Thanks for your help but right now I am the programmer and "security >>> consultant", and therefore I must come up with security answers. >>> Nonetheless I will mention to my employer that he might want to hire >>> another person as a "security consultant" to deal with server side >>> security issues. >>> >> >> And that is one of the problems which people are trying to describe. >> >> Where the application coding can be split between server and client >> side coding - (and evidently has been, you have the client side chore). > > While I have programmed the client side, I am not precluded from working > on the server side code/scripts nor from accessing the server side > database. > >> >> The system security plan can not be split, it must encompass the >> application >> as a whole, end-to-end. >> >> Note I write: "plan" - the coding that implements the plan can be split, >> just the plan can not be. >> >> And unfortunately for yourself, you can't fix things from the client >> side only. ;) > > See above. > >> >> - - - - >> >> From a business stand point, there is another significant problem >> lurking here - >> >> If the system was sold along the lines of argument: "Buy our xyz and >> you can be sure the information in the system is secure." >> >> The the customer can reasonably expect the firm making the sale under >> such >> logic to be responsible for any security failures. >> >> Now consider some scheme that involves a client-side private key - - >> Perhaps, the application generates a key-pair, has the server sign the >> certificate request - something, anything, that results in a client side, >> private key - - >> >> If any of the clients fail to preserve and protect that client side >> private key - >> Then the information stored by the application is subject to compromise. >> I.E: the actual failure point is on the client side - >> But the liability remains with the provider of the system. Ouch. >> (You can't ask the Fox to protect the Chicken House.) >> >> A similar case can be made for a system that does not use a client >> side private >> key but requires protection of the public key materials on the client >> side. > > Well I asked whether protection for the client side certs were needed, > and how this might be done, and I was told I was barking up the wrong > tree, so to speak. I felt this way from the very beginning but my > employer wanted to get other opinions. > > But other than vague remonstrances about security planning, and that I > was not qualified as a mere "programmer" to handle security issues from > people who have no idea about my ability, I have yet to receive any > specifics from others about what they would do in this very common > scenario to implement security for the data in the server database. > > I am a very experienced programmer/designer/architect and vague talk > about security does not really impress me very much. Of course if you or > others would like to get technical and mention what you feel are good > technical solutions to any problems which entail private-key/public-key > encryption, I am willing to listen and learn about things which I do not > fully know or understand. > > Once again the specific issue is that the MySQL server database has a > certificate from a CA authority with a server public-private key and my > client application was issued the same certificate from the CA authority > with a a client public-private key. I need to pass the file location of > the client CA certificate/public-key/private-key to the client side > library in order to have an SSL connection to the database server where > data passing between the client application and the server database is > encrypted both ways. I told my employer that we should simply distribute > the client CA certificate/public-key/private-key in the same application > directory in which the rest of our modules reside. He had been told by > someone from Sun that this was inherently bad security and, despite my > arguing that this was not the case and that without the > username/password to the database nothing could be accomplished even > with the client side certs by a destructive hacker, he wanted me to > investigate the issue. > > From what others have written, I feel that I am right and coming up with > elaborate schemes of hiding the client certs from the end-user until > thay are actually going to be used by client application code in making > the connection is largely a waste of time. Instead we should be ensuring > that the server database and its data are protected from the prying eyes > of a destructive hacker. > > ______________________________________________________________________ > 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
