Hello Martin, I am not OpenSSL developer so this message will contain only my own opinions.
Security provided by the default CSP in Windows (I think its name is "Microsoft Enhanced Cryptographic Provider" or something like that) is same as security provided encrypted PEM file. Default CSP stores your private keys in your home folder - yes they are "transportable" - and your password is used to protect them. If you don't believe me try reseting, not changing, your password then use your key to sign data - it will not work - then reset your password back to its original value and sign data - it will work. I am not sure if I understand you correctly but I think that you are missing ONE standardized API that could be used by all or most of the applications available for linux/unix platform. There have been several attempts to create such API like QCA (Qt Cryptographic Architecture) from KDE project - http://api.kde.org/kdesupport-api/kdesupport-apidocs/qca/html/ - that IMHO tries to achieve similar functionality like MS Crypto API on Windows platform. There is also multi-platform JCA (Java Cryptography Architecture) - http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html - but that is available only for Java applications. PKCS#11 - http://www.rsa.com/rsalabs/node.asp?id=2133 - has to be also mentioned when speaking of cryptographic API. It was designed as API for accessing cryptographic hardware but there are also implementations for pure software tokens. PKCS#11 is supported by Mozilla applications (Firefox, Thunderbird, ...). OpenSSL provides ENGINE API that allows developers to extend library with support for cryptographic hardware and it also allows them to leverage good things from other software implementations. For example one can write engine that uses GnuTLS implementation of cryptographic algorithms through standard OpenSSL calls. When speaking of CSP there is already CAPI engine available (engines/e_capi.c) that can be used to access objects in certificate store of MS Windows. As you can see there are many "crypto APIs" available and every developer can choose his own path. So my question is: How would you convince 3rd party developers to use your implementation with "CSP server" ? Kind Regards Jaroslav On Thu, Jun 3, 2010 at 12:15 PM, Martin Gwerder <[email protected]> wrote: > Hi All > > Recently we built a Linux based system setup which is heavily relying on > X.509 certificates. On this occasion we had to realize that there is no > such thing as a client CSP available on Linux or UNIX (neither free nor > comercial; At least nothing which might be well supported by apps; If I > have overlooked something let me know). This ends in the paradox situation > that unless stored in a physical secured store (smartcard) a certificate > identity may only be used by exposing the certificate file directly to the > user using it (which makes it "transportable"; I am well aware that a root > user may always transport a certificate unless stored in an apropriate HW > store). > > All the following text is just a couple of thrown thoughts. Feel free to > comment and/or criticize it. > > It usually would make no sense to implement a CSP as it would require that > we would have to implement the support for the respective CSP into each > and every application. There is however a solution which might work. As > OpenSSL is widely used in lots of applications it would be a thing to > consider the following: > > OpenSSL would have to be modified as follows: > > - Implement a "dual use" for certificates which allows to > - Either use an "ordinary" certificate (to be used as of now) > - or a CSP configuration which contains the configuration where and > how to get the certificate services > - Implement a certificate service provider daemon in OpenSSL which offers > access thru named sockets or network sockets > - Implement a CSP configuration generator in OpenSSL which creates CSP > configuration files which can be distinguished from a certificate at any > time. > > This modification of the OpenSSL library would allow to make the > certificates more secure and allow applications without (!) any code > modification (just by linking against the CSP capable OpenSSL library) to > support the CSP. > > I am well aware of the magnitude of the proposed change. I futhermore > intentionally left out a couple of important details (such as how would > the client authenticate against the CSP server or how is the CSP daemon > configured). I am furthermore aware that introducing such a client/server > design would introduce a new SPOF and a couple thoughts should be wasted > towards that direction as well. > > I have not seen any features covering the purpopse of the above mentioned > changes. I would be however more than happy to hear that all of it > allready exists. > > I would be very glad if someone would raise either a cople of concerns or > shout for its implementation (or both). > > Regards > Martin > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
