Hi Martin: I'll jump on this :)
On June 3, 2010 06:15:13 am Martin Gwerder 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). > Not sure where you are going it - even on Windows "CSP", if you know where to look, the keys are always "transportable" - even if you set the private key to non-exportable, just backup the system, and restore it somewhere else ... not to mention the fact that there are several APIs that you can use to expose the private key. I think ANY software based key system that claims to make claim that it prevents private key transport is rather in the "snake oil" category. > 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. > OpenSSL is a toolkit... and quite a good one for doing the crypto bits... a fully featured "Crypto Service Provider" has two functions - storing keys, and validating other peoples keys. Ideally, there is some key management functions in there as well, to handle rekey/revocation/renewal/what-have-you. A couple of notes: 1: Hooking things like CRL retrieval, AIA chasing, OCSP checking, CMS/XKMS/TAMP communication with the CA, etc., into OpenSSL, and having it do all of the network communications would mean that you'd have to have some way of hooking the applications main loop (if you blocked on a network access, someone is liable to get VERY angry with you :). Even if you were to implement a client/server type scenario, you'd still have to be quite smart about it, and modify the application accordingly. 2: You could do SOME of what you are thinking of using the engine interface - issue 1 still holds, but you could implement some of the functionality in the engine to handle access to the keystore, and validation. 3: Part of what you are thinking of, I think, is already done by applications such as Pathfinder (http://www.carillon.ca/tools/pathfinder.php). It does full RFC5280 PDVal, and can act as a central trust store and settings manager. 4: OpenSSL is used in many server side applications, but very few client apps. Servers tend to be protected physically (in data centers with restrictive access), and logically (login capability is generally restricted to a select few people, and MOSTLY done right..). Linux Client side certificate management, on the other hand, is a mess. KDE/Kontact/Konqueror uses KSSL/Kleopatra, Firefox/Thunderbird/Evolution/OpenOfficeOrg use libnss, and each have their own keystores (or at least, most of the time, they don't share them). Adobe uses goodness knows what. Java uses it's own keystore unless you tell it not to, etc. Most of the applications that actual users will touch on a daily basis use something other than OpenSSL. And even of those that do use OpenSSL, most don't do it right (very few obey settings such as Engine configs for keys out of the central "main" openssl.cnf, and few still allow you to specify a different openssl.cnf.) What I can see is needed is for these projects to come together and make a few decisions regarding a common user key store, a common machine key store, and a central trust anchor store. That would be a HUGE start in usability. > 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. > Again - just wrapping something in a box doesn't make it any more secure - security comes from many more methods than that. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
