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