[CSP11] MinGW build and lots of fixups

[Alon Bar-Lev]

Hello,

I've created MinGW based build for csp11. I've found some issue,
especially regarding unicode and unsigned handling (unsigned < 0).

Most should be corrected, but I have no way to test this.

Branch at [1].
Diff at [2].
Tarball at [3].

A lot of other warnings an potential errors still exists, maybe there
is an alternative? How is maintaining this?

Thanks!
Alon.

[1] http://www.opensc-project.org/svn/scb/branches/alonbl/mingw/csp11
[2] svn diff -r 84:HEAD
http://www.opensc-project.org/svn/scb/branches/alonbl/mingw/csp11
[3] http://alon.barlev.googlepages.com/csp11-0.5.0-svn.tar.gz
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Andreas Jellinghaus-2]

Hi Alon,

Am Donnerstag, 20. März 2008 23:31:19 schrieb Alon Bar-Lev:
> I've created MinGW based build for csp11. I've found some issue,
> especially regarding unicode and unsigned handling (unsigned < 0).

great. which source did you use? I think we have the imported repository
with trunk, several versions, and we have one branch with a modified copy
by someone else.

I never got a copy working myself, only the self-signed release from csp11
home page worked for me. but I no longer have a windows machine for testing,
so I can't be of any help here either.

> A lot of other warnings an potential errors still exists, maybe there
> is an alternative? How is maintaining this?

noone is maintaining CSP#11 I think.

the alternative would be PKCS-CSP, which we also host on opensc-project.org,
but which is also unmaintained. I think it handles some stuff better, and a
few people reported success with this or that modification. but I never got
around to build it myself and test it - no windows here any more.

for pkcscsp you can see three release/ branches by different people and the
trunk source folder from the upstream developer might have changes too.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Emanuele Pucciarelli-2]

Hi all,

> noone is maintaining CSP#11 I think.
>
> the alternative would be PKCS-CSP, which we also host on opensc-
> project.org,
> but which is also unmaintained. I think it handles some stuff  
> better, and a
> few people reported success with this or that modification. but I  
> never got
> around to build it myself and test it - no windows here any more.

I have one more alternative – I have written a smart card minidriver  
for the Base CSP architecture. It's beta-ish, but it correctly handles  
IE connections; I haven't tested Outlook et al. yet, but they should  
be fine.

The big advantage is that it is short (less than 2000 lines before  
clean-up) and it does not need signing by Microsoft.

The disadvantages are that (1) it only runs on Windows XP+ (Vista  
included) and (2) it requires a hack in reader-pcsc.c. In detail,  
Windows connects to the card first, and then passes a PC/SC context  
and handle to the minidriver. Therefore, I had to modify reader-pcsc.c  
to read pointers to them from the environment. It is not beautiful,  
but there should not be any security implications since this behaviour  
can be turned on or off from the main OpenSC configuration file.

If it sounds "good enough" an idea, I'm going to push myself to clean  
it up and release it a little earlier :)

Regards,

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

[Alon Bar-Lev]

On 8/25/08, Emanuele Pucciarelli <ep@...> wrote:
> (2) it requires a hack in reader-pcsc.c. In detail,
>  Windows connects to the card first, and then passes a PC/SC context
>  and handle to the minidriver. Therefore, I had to modify reader-pcsc.c
>  to read pointers to them from the environment. It is not beautiful,
>  but there should not be any security implications since this behaviour
>  can be turned on or off from the main OpenSC configuration file.

Can you please explain some more?
Actually, I would like to see a generic minidriver that use PKCS#11,
so it able to use any provider out there.
Maybe you can fake a handle and delay the connection?

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

[Emanuele Pucciarelli-2]

Il giorno 25/ago/08, alle ore 08:49, Alon Bar-Lev ha scritto:

> Can you please explain some more?
> Actually, I would like to see a generic minidriver that use PKCS#11,
> so it able to use any provider out there.
> Maybe you can fake a handle and delay the connection?

I would like that too, but I can't see how to do it, unfortunately.  
The Base CSP opens the card connection in exclusive mode, at least at  
login, and I think (I haven't tried it out!) it is kept that way until  
the operations that require the login have finished. So I'm expected  
to return valid results, e.g. a signature, before Windows releases the  
exclusive connection…

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

[Andreas Jellinghaus-2]

Hi Emanuele,

> I have one more alternative – I have written a smart card minidriver
> for the Base CSP architecture. It's beta-ish, but it correctly handles
> IE connections; I haven't tested Outlook et al. yet, but they should
> be fine.
>
> 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?

> 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.

> (2) it requires a hack in reader-pcsc.c. In detail,
> Windows connects to the card first, and then passes a PC/SC context
> and handle to the minidriver. Therefore, I had to modify reader-pcsc.c
> to read pointers to them from the environment. It is not beautiful,
> but there should not be any security implications since this behaviour
> can be turned on or off from the main OpenSC configuration file.

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).

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).

> If it sounds "good enough" an idea, I'm going to push myself to clean
> it up and release it a little earlier :)

great!

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. do you need any special tool with your approach?

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)?

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?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Emanuele Pucciarelli-2]

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@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Alon Bar-Lev]

On 8/25/08, Emanuele Pucciarelli <ep@...> wrote:
>  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.

Latest version supports modifying the pcsc provider.
Use provider_library configuration option.

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

[Andreas Jellinghaus-2]

Am Mittwoch, 27. August 2008 05:33:19 schrieb Wan-Teh Chang:
> I suggest that you consider the Coolkey CSP:
> http://directory.fedoraproject.org/wiki/CoolKey#Windows_CSP
>
> The Coolkey CSP is fully implemented: it supports signing,
> decryption, and Windows smartcard logon.

hmm. I always thought coolkey wasn't generic. but the CSP module
looks like it uses PKCS#11 tokens - at least I see pkcs#11 header files
there. the code mentions Identity Alliance all over the place - is this
the ID Ally CSP now open sourced?

ID Ally CSP always worked fine for me. If it ever got open sourced,
I didn't know. Also the Coolkey wiki page doesn't explain much of
what coolkey exactly does. I always thought coolkey was the successor
of the Netscape Smart Card software for the US Army and thus limited
to cyberflex cards with it's own applet. if the CSP is generic, that would
be great.

Still the MS base CSP für smart cards might have advantages, as the
infrastructure MS provides with it sounds quite nice.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Douglas E. Engert]

Andreas Jellinghaus wrote:

> Am Mittwoch, 27. August 2008 05:33:19 schrieb Wan-Teh Chang:
>> I suggest that you consider the Coolkey CSP:
>> http://directory.fedoraproject.org/wiki/CoolKey#Windows_CSP
>>
>> The Coolkey CSP is fully implemented: it supports signing,
>> decryption, and Windows smartcard logon.
>
> hmm. I always thought coolkey wasn't generic. but the CSP module
> looks like it uses PKCS#11 tokens - at least I see pkcs#11 header files
> there. the code mentions Identity Alliance all over the place - is this
> the ID Ally CSP now open sourced?
>
> ID Ally CSP always worked fine for me. If it ever got open sourced,
> I didn't know.

Some of the files have: "Copyright (C) 2003-2004 Identity Alliance"
with a GPL2 license. It does not look like all of ID Ally,
I don't see the card Manager, but it might be enough.

> Also the Coolkey wiki page doesn't explain much of
> what coolkey exactly does. I always thought coolkey was the successor
> of the Netscape Smart Card software for the US Army and thus limited
> to cyberflex cards with it's own applet. if the CSP is generic, that would
> be great.

Looking at the source, it looks Generic and loads a PKCS#11 dll.

>
> Still the MS base CSP für smart cards might have advantages, as the
> infrastructure MS provides with it sounds quite nice.

The source is small, and does use the Microsoft CAPI CSPDK.


>
> Regards, Andreas
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@...
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <DEEngert@...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  [phone]
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Wan-Teh Chang-2]

The Coolkey CSP is generic -- I remember it loads the PKCS #11 module
specified in a registry key.  So you can use the Coolkey CSP with your
own PKCS #11 module.  The Coolkey CSP is actually independent of the
rest of the Coolkey project.

Before the Coolkey CSP was available, I looked at both CSP11
and pkcscsp (http://www.ilex.fr/en/opensource/pkcscsp.htm).  After
comparing the two, I decided to go with pkcscsp because it supports
email decryption.  I exchanged some patches for pkcscsp with
Dejan Gambin by email.  The Coolkey CSP is more complete
than CSP11 and pkcscsp because it also supports Windows smartcard
logon.  In spite of that, I think CSP11 and pkcscsp both have some
good ideas.  I hope the licenses of these projects allow code snippets
to flow easily between them.

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