Re: [opensc-devel] lsm pkcs#11 ?
Hi Clizio, I think spliting client and server is the right thing to go. While I share Alons reservations when it comes to using tcp/ip, I don't see a reason to not do that, if someone wants to do that. might work well in thinclient environments etc. currently we have a big fat library loading other libraries into an application. a small module talking to a daemon looks much nicer, can implement single sign on like alon mentioned, and solves a number of problem - e.g. makes it much easier and cleaner to implement gui popups (e.g. for lawful digital signatures, letting the user know he has to enter a pin (on the reader with pinpad) and so on). also it might be interesting to have a full featured store - one that contains the local file based certificates and keys etc. as well as the smart card stuff. one interface for all applications. ms crypto api is the right idea I guess - much better if you have one interface for all apps, than have every app manage certficates and all that on their own. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] lsm pkcs#11 ?
Andreas, my idea is to support PKCS#11 interface on both sides... Thus nothing actually gets simpler... Just keep standard while providing singe sign-on and more secure environment. I am strongly against developing a new API for application to use... full feature store. The application will load proxy PKCS#11 which will forward all requests to a daemon. The daemon will load several PKCS#11 provider and expose them to the application as if they were a single provider. The only functionality the daemon will use is PIN management. This way application will be required to support PKCS#11 and only PKCS#11. If the user chooses he can load the smartcard provider into application or he can use the daemon in order to provide SSO. For CAPI... I've seen implementations of PKCS#11 which can access CAPI stores... And it this will be the problem, I can develop one too... Best Regards, Alon Bar-Lev. On 4/24/07, Andreas Jellinghaus [EMAIL PROTECTED] wrote: Hi Clizio, I think spliting client and server is the right thing to go. While I share Alons reservations when it comes to using tcp/ip, I don't see a reason to not do that, if someone wants to do that. might work well in thinclient environments etc. currently we have a big fat library loading other libraries into an application. a small module talking to a daemon looks much nicer, can implement single sign on like alon mentioned, and solves a number of problem - e.g. makes it much easier and cleaner to implement gui popups (e.g. for lawful digital signatures, letting the user know he has to enter a pin (on the reader with pinpad) and so on). also it might be interesting to have a full featured store - one that contains the local file based certificates and keys etc. as well as the smart card stuff. one interface for all applications. ms crypto api is the right idea I guess - much better if you have one interface for all apps, than have every app manage certficates and all that on their own. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] lsm pkcs#11 ?
Hello, I have a plan to write a PKCS#11 proxy which offers PKCS#11 interface to application and work with PKCS#11 provider at daemon side. This will enable to solve two issues: 1. Do not allow a PKCS#11 provider to mess with main process memory. 2. Allow single signon for user desktop, by identifying as secure authentication path enabled token, and managing PIN prompt separately. This way many applications can load the same library, and if the process authorized to use socket they can access already authenticated session. The interaction between the client and server can be made using TCP socket, so this is a great way to solve the HSM issue as well... All you need to expose is local PKCS#11 interface... Best Regards, Alon Bar-Lev. On 4/22/07, Clizio [EMAIL PROTECTED] wrote: Excuse me if I enter into this discussion. But, as the author of LSM-PKCS11, I'd like to answer to the question: Why a daemon is required? The aim of the package is to implement the necessary tools to build an HSM-like device. Apart from tampering problems, an external machine implementing security functions such as key-pairs creation and storing, signatures, cryptos and so on, is a 'server': and a server is always implemented with background processes dialoguing with a specific protocol and making something (i.e. a service 'daemon'). Only with a daemon it is possible to break the client side (PKCS11 driver) from the actual server side, leaving the daemon on the server. A simpler solution is the inclusion of the service within the PKCS11 module itself, but this would lead to a simple local software-emulation of a smart-card: functionally correct, but very limited in use. The client/server approach is open to both solutions: a stand-alone local security device, and a network security module accessible from many clients at the same time. Not a real HSM, but for a limited hardware budget of 200 dollars you get a lite solution that can be logically tampered with proper security policies and counter-measures. As we say in italian: ... e dimmi se e' poco... (tell me if this is nothing). Best Regards Clizio Merli Alon Bar-Lev wrote: Hello Andreas, Why a daemon is required? Can't the card transaction be used to sync between instances? And if caching is required you can cache certificates by thumbprint at user home... Best Regards, Alon Bar-Lev. On 3/6/07, Andreas Jellinghaus [EMAIL PROTECTED] wrote: http://www.clizio.com/lsmpkcs11.html did anyone have a look at this software and try it? if it does what I think and if we could attach opensc to the daemon side of it, then we might be able to to real locking etc, and still have multi applications access a card - if the daemon caches the certs etc. not sure if that idea works out, but might be worth a look. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- View this message in context: http://www.nabble.com/lsm-pkcs-11---tf3360425.html#a10125453 Sent from the OpenSC - Dev mailing list archive at Nabble.com. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] lsm pkcs#11 ?
The project is actually implementing a software security module (rather than a hardware security module / HSM) that uses a client/server approach with a PKCS#11 library on the client side. You run the deamon on one machine and use the PKCS#11 library on the client to access the cryptographic token. Cryptographic material is stored in a file on the server which is protected by some crypto-scheme. In a simplistic scenario that does not require any FIPS or ITSEC evaluated key store, you could put the server into a vault and have a cheap and minimalistic HSM (no tamper resistance however). The project can replace a HSM with a software implementation, but it does not allow to use PKCS#11 modules on the server (which is guess is what Andreas is looking for). Kind regards, Andreas Alon Bar-Lev schrieb: Hello Andreas, Why a daemon is required? Can't the card transaction be used to sync between instances? And if caching is required you can cache certificates by thumbprint at user home... Best Regards, Alon Bar-Lev. On 3/6/07, Andreas Jellinghaus [EMAIL PROTECTED] wrote: http://www.clizio.com/lsmpkcs11.html did anyone have a look at this software and try it? if it does what I think and if we could attach opensc to the daemon side of it, then we might be able to to real locking etc, and still have multi applications access a card - if the daemon caches the certs etc. not sure if that idea works out, but might be worth a look. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] lsm pkcs#11 ?
Thanks! There is always egg and chiken conflict with this kind of approach... In order to communicate with remote daemon using TCP/IP you need to authenticate... But you cannot authenticate since you cannot access the token... This problem is common for most HSM modules as well... Not all allow to use local smartcard in order to open a session to remote HSM. I was more concerned regarding the statement that locking and multi-application cannot be implemented without a daemon component. It sounds a bit strange as I know several providers which implement this. Best Regards, Alon Bar-Lev. On 3/10/07, Andreas Schwier [EMAIL PROTECTED] wrote: The project is actually implementing a software security module (rather than a hardware security module / HSM) that uses a client/server approach with a PKCS#11 library on the client side. You run the deamon on one machine and use the PKCS#11 library on the client to access the cryptographic token. Cryptographic material is stored in a file on the server which is protected by some crypto-scheme. In a simplistic scenario that does not require any FIPS or ITSEC evaluated key store, you could put the server into a vault and have a cheap and minimalistic HSM (no tamper resistance however). The project can replace a HSM with a software implementation, but it does not allow to use PKCS#11 modules on the server (which is guess is what Andreas is looking for). Kind regards, Andreas Alon Bar-Lev schrieb: Hello Andreas, Why a daemon is required? Can't the card transaction be used to sync between instances? And if caching is required you can cache certificates by thumbprint at user home... Best Regards, Alon Bar-Lev. On 3/6/07, Andreas Jellinghaus [EMAIL PROTECTED] wrote: http://www.clizio.com/lsmpkcs11.html did anyone have a look at this software and try it? if it does what I think and if we could attach opensc to the daemon side of it, then we might be able to to real locking etc, and still have multi applications access a card - if the daemon caches the certs etc. not sure if that idea works out, but might be worth a look. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] lsm pkcs#11 ?
http://www.clizio.com/lsmpkcs11.html did anyone have a look at this software and try it? if it does what I think and if we could attach opensc to the daemon side of it, then we might be able to to real locking etc, and still have multi applications access a card - if the daemon caches the certs etc. not sure if that idea works out, but might be worth a look. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
