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
