Il giorno 25/ago/08, alle ore 14:01, Andreas Jellinghaus ha scritto:

>> The big advantage is that it is short (less than 2000 lines before
>> clean-up) and it does not need signing by Microsoft.
>
> nice. do you use opensc code directly, or do you use the PKCS#11  
> interface
> to opensc-pkcs11.dll?

I use the PKCS#11 interface. That's almost a must – myself, I wouldn't  
know any interface really well, so PKCS#11 has the advantage of being  
thoroughly documented…

>> The disadvantages are that (1) it only runs on Windows XP+ (Vista
>> included) and
>
> I don't think users of Win2K and older are likely to start using  
> smart cards.
> so I wouldn't worry about this one.

Agreed. Especially as things are even better: I'm checking it now, and  
KB909520 provides a version of Base CSP that runs on Windows 2000 SP4.  
Only Windows 9x/ME are left out, then.

>> hmm, if the hack is config file enabled, people would need to switch
> edit it, when switching from outlook/ie/login/... to cmd line tools/ 
> putty/...
> and back? maybe some other solution could be used (like environment
> variables - easy way to store some text value that the library code  
> can
> reach).

Actually, I'm doing both. The configuration file has the names of the  
environment variables to check for; if they are missing, or if the  
conversion of the pointer fails, then it behaves as though there were  
no hack.

> sure it remains a hack, but I think it is most important to find one  
> well
> working solution (as there are generic but not always well working
> alternatives already - csp11 and pkcscsp).

Now that you made think of it, there is a cleaner hack: a replacement  
winscard.dll, in the spirit of APDUVIEW. The interface is thankfully  
standard, so we can write a new winscard.dll that opens the original  
one upon loading. If there are no environment variables, or they are  
not valid, then it calls the corresponding function of the original  
DLL without performing any operation. If there are, then (1) it only  
enumerates one reader and one smart card, the one that has been  
already opened; (2) it reports successful connections/disconnections  
without actually doing anything, and returns the pre-opened handles to  
the calling application; (3) when it is called with those same handles  
by the application, it forwards the parameters to the original DLL and  
performs the APDU transfers, transparently returining buffers and  
results to the calling application.

It shouldn't be difficult, and it should work with all PKCS#11  
libraries, provided that it is installed by dropping the "fake"  
winscard.dll in the same directory as the PKCS#11 DLL.

>> one question: I think both CSP#11 and pkcs-csp had some tool to  
>> "register"
> certificates or similar, but I don't know the details about what the  
> tools
> did and why.

It's fairy awful; CSP11 comes with a 1000-line C program to do just  
that. These tools add the certificate to Windows' certificate store,  
so that it knows that the user owns the certificate and has a private  
key for it, and it knows what is the responsible CSP for it.

> do you need any special tool with your approach?

Luckily everything is provided by the Base CSP, so the user still has  
to register the certificates, but it is done via Microsoft's standard  
interface, and possibly some applications handle it on their own. (At  
least for testing, "certutil.exe -scinfo" is enough to do everything,  
it tests the smart card and pops up a certificate listing where you  
can just click OK to install the certificate; and it's likely that  
there are some other completely mouse-friendly shortcuts.)

> also I wonder: if the smart card mini driver opens pcsc with locking  
> the
> driver - how can several applications use the smart card? for example
> internet explorer, outlook and the GINA (login screen / screen lock)?

Correct; to be precise, the Base CSP opens the card in exclusive mode  
and passes the handle to the minidriver. I think that this only  
happens when the user has to log in, though. After the "sensitive"  
operation is done, the Base CSP asks the driver to deauthenticate (or  
to reset the card, if there is no "logout"/"deauthenticate" function)  
and releases the lock.

It also keeps a cached copy of the PINs, so that when the same  
application wants to log in, Windows can perform the verification  
behind the scenes, without bothering the user; performs the actual  
operation; and then deauthenticates and releases the lock again.

> did microsoft a central service that the applications talk to, or  
> does the
> driver need to read all public info and then close the pcsc driver,  
> so other
> apps can open it? or some other solution?

Both are correct; all the applications that use the CSP API talk to  
Windows, which talks to the Base CSP provider, which chooses the right  
minidriver and talks to it. But if an applications wants to use PC/SC  
directly, or by linking to a PKCS#11 library, then it can do so; the  
only obstacle is that it will hang while another application has the  
lock, but, if I understand correctly, the lock is always released ASAP  
by CSP.

It seems much more likely that a PKCS#11 library may grab the lock  
after C->Login() and make CSP apps hang until the lock is released…

Bye!

-- 
Emanuele
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to