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
