On 2/11/2011 3:13 AM, Martin Paljak wrote:
Hello,
On Tue, Feb 8, 2011 at 22:42, Douglas E. Engert<deeng...@anl.gov> wrote:
On 2/8/2011 1:29 PM, Andre Zepezauer wrote:
Hello Douglas,
please have a look at that picture [1]. FYI the cardmod resides on the
same level as OpenSC.tokend does. As you can see, there is a clear
distinction between the library 'libopensc' and the applications (shown
at the top).
Yes, cardmod would be a box next to tokend with a line to libopensc. But
the BaseCSP passed reader and card handles to cardmod. These need to be
passed to the PC/SC driver. That would be a line from the cardmod box
to the PC/SC box. That line is implemented by use_reader.
The more I thought about this and were is belongs on the diagram, cardmod
is more like the PKCS#11 interface to the underlying PKCS#15 modules. Cardmod
implements the API defined by Microsoft. It does not use any of the slot
concepts
used by PKCS#11, but provides the PC/SC handles to access a specific
card. The Microsoft code has already detected the reader and card and
read the ATR and determined that the opensc-cardmod is the handler
to be used.
OpenSC.tokend is separate from the rest of OpenSC mostly because of two reasons:
* Licensing (OpenSC.tokend is derived from APSL code and is not LGPL)
* Braindead OS X specific build process (you need to have private
binaries from OS X "open source" program to link a tokend). Those
pieces used to be built 100% from source under the SCA umbrella (in
line with the official documentation from Apple) with darwinbuild but
that was a stupid and time consuming procedure. Now the necessary
binaries were pre-fetched from Apple and pre-bundled by me (you can
re-do the procedure if you want, the helper script is available in
OpenSC.tokend git, packaged pieces for 10.5 or 10.6 weight around 40M
each) and the build is simpler. Maybe things have improved even more
recently and there are further improvements to be made to the build
process of OpenSC.tokend, but that needs time to investigate.
Volunteers are most welcome, I don't have the time to dig deep into
this but I can give helpful advice as needed.
Licensing with MiniDrivers is important as well, to my knowledge MS
will not accept any LGPL code into the "autodiscovery" list of modules
that could be put into Windows update and would auto-install the
MiniDriver with Windows 7.
Interesting.
Platform adapters should be "core" of OpenSC. How they are bundled in
terms of source packages or distributed as binaries is a different
story. But conceptually they are "part of OpenSC", not "external
applications".
So based on my comments above, cardmod is more of a "core" routine,
exposing the Microsoft CNG API rather then the PKCS#11 API.
So, if there is a problem within a particular application, that problem
should also be fixed within the same application. If that isn't possible
at all, then improvements in libopensc may be considered.
(The term application is vague. Cardmod is not the application, is is a
module under the BaseCSP. The application could be IE, login, certutil etc.)
All of the existing applications that use OpenSC allow the reader drivers
to find reader and cards on their own. The reader drivers do the detection,
and all the reader and card communication.
Correct. This is one place where practicality beats purity. The task
of OpenSC is to expose the smart card to users (applications) in the
most convenient way. This means as good platform integration as
possible for the native users (native applications using native
API-s).
Like the Microsoft CNG API that cardmod.c implements.
libopensc is not set in stone, it does things that could be done
differently and the only reason why this is not yet done is legacy.
Legacy like mostly unused multi-reader-driver-framework.
Maybe this is the way cardmod should have been implemented?
Adapting to
requirements and external restrictions is necessary. Unlike Linux, we
can't affect how MSFT or AAPL creates their frameworks and
applications, we must adapt. Taking into account the amount of Windows
installations out there it is a very good reason to adjust libopensc
to real life.
It has been a healthy discussion about minidrivers and necessary PC/SC
adjustments this far, much better for the overall health of OpenSC
than "we need a flag to omit some internal calls" approach or using
registry as a function parameter passing mechanism :)
There is still Brian's issue. He says he has a CSP or is it a mini-driver
that can use OpenSC if sc_ctc_detect_readers is not called. He still has
not said how he does it. Brian???
What are you talking about?
In some of your notes you were proposing different entry points
for different reasons. These might be good ideas for some
future projects. One note talked about combining the original
pcsc and modified copies of these routines used for cardmod,
to reduce the redundent code.
I've said this before: the way I see it, reader-*.c files translate
between sc_* API and the reader API that is implemented. cardmod is
not a reader driver, it is a set of conventions when dealing with
Windows winscard API, that were not "available" in the reader-pcsc.c
code at that time.
Its more then dealing with the winscard API. The mini-driver is
implementing a generic file structure for the card with file names like
cardid, cardcf, cmapfile, kscNN, kxcNN and cardapps in the mscp directory.
Its more like the PKCS#11 routines on top of PKCS#15 with a specific
reader and card.
Those deficiencies in current PC/SC code never triggered a healthy
discussion when the cardmod code was commited, unfortunately.
The more I look at the cardmod modifications in reader-pcsc.c
they look like they could be merged with the original code.
Now that the use of the registry is removed from reader-pcsc.c,
I compiled OpenSC on Solaris without the #ifdef CARDMOD_ENABLED line
in reader-pcsc.c and it compiled and runs. See attached patch which also
removed on unused line "HKEY key;"
Since the BaseCSP will pass in the PC/SC handles to be used, all
of the functionality of reader-pcsc that dealing with finding readers,
connecting to cards and handling reader removal are not used with cardmod,
as they are handled by the Microsoft code. The cardmod modifications to
reader-pcsc for the most part turn off all these features, so they don't
get accidentally executed and cause problems. The way this was done was
to copy most of the routines and delete unwanted code. That is why I am
saying there is a lot more that could be done to clean it up.
Discussion about tasks that the code in reader-pcsc.c should do, the
necessary extra entry points
There is only one extra entry point, use_reader with 2 parameters.
(yes, only PC/SC, don't bother thinking
about CT-API or OpenCT here)
I agree. In these drivers the *_use_reader = NULL;
or the necessary calls that should be
additionally done by "applications" instead of reader or libopensc
code (sc_detect_readers) to adopt to the requirements that would
satisfy all callers need to be designed.
The difference with the cardmod vs any other caller of opensc is the
PC/SC handles are provided and are being managed by the calling application.
All the PKCS#11 applications and opensc tools expect opensc
libs to find the readers and cards.
Furthermore, any cardmod adjustments can be implemented and isolated
with ifdef-s,
The only #ifdef ENABLED_CARDMOD left is in ctx, and that could easily be
removed as it tests the app_name for "cardmod" (The cardmod/Makefile.am
has one to compile or not.) That test for the app_name is needed today
because of the way the readers are initialized, and the cardmod looks
like a separate driver. This could change if the mods were merged better
in reader-pcsc.c
as it can be built separately from "OpenSC, the PKCS#11
and command line tools distribution". A minidriver should be
distributed as a single DLL (as described in the spec), it could thus
be distributed separately from the rest of OpenSC (like in some
corporate environment where the only job of OpenSC minidriver is to
provide the ability to authenticate with IE after the IT department
has issued cards personalized with OpenSC to empolyees)
That is an option, it could also be distributed with the opensc
package, as even on Windows sometimes one want to use PKCS#11.
As a side note, I use Thunderbird on W7. Some people like FireFox too.
It is a bit of a hassle, as there are two certificate stores,
on the same machine, and you need to register your card
and its CA certs with both the Microsoft cert store and the NSS.
NSS does have a nsscapi.dll (that is not built by default)
that lets NSS use the Microsoft certificate store and CSPs
and Mini-drivers. So the need for PKCS#11 may be reduced in the
future on Windows. But opensc with cardmod would still be usable.
Part of the problem with the mini-driver is trying to understand
what Microsoft is really doing, especially without having their
source code. Being able to test a modification is a big part of
the development process. That is why I was asking if you have
and environment to build and test any cardmod changes.
This is where Jenkins should start to help, see my previous e-mail about it.
Right now, the virtual machines run in my PC, which could easily host
a dozen of different machines, but has limited access to the internet
(1024K/512K). So a per-commit build with installer upload is not
feasible at the moment, I've configured daily builds only. If somebody
has a Windows machine with better network connection, it can be used
to a) repeat the native build process b) provide the build result as a
download through opensc-project.org. The necessary environment setup
is quite simple: Platform SDK (500M download), Java (for running
Jenkins slave), CNGSDK (for cardmod headers), OpenSSL (right now the
slpro binary is used, but probably shall be built as well in the
future). The node must not be connected 24/7 to be useful.
Information about all this will end up in OpenSC wiki eventually,
right now please ping me privately (or on the list) if you want hook
in. The ultimate goal is to be able to provide installers with
natively built code for every source commit. My guesstimate is that
this will happen in about 1 to 1.5 months.
I like the naively built code, but I must admit the mingw works a lot
better then I had expected, and also builds the openssl and zlib
as well as some other modules.
Cheers,
Martin
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Index: reader-pcsc.c
===================================================================
--- reader-pcsc.c (revision 5192)
+++ reader-pcsc.c (working copy)
@@ -1540,7 +1540,8 @@
return &pcsc_drv;
}
-#ifdef ENABLE_CARDMOD
+//#ifdef ENABLE_CARDMOD
+#if 1
#define SCARD_CLASS_SYSTEM 0x7fff
#define SCARD_ATTR_VALUE(Class, Tag) ((((ULONG)(Class)) << 16) |
((ULONG)(Tag)))
@@ -1676,7 +1677,6 @@
char reader_name[128];
DWORD rcount, feature_len, display_ioctl, reader_name_size =
sizeof(reader_name);
int ret = SC_ERROR_INTERNAL;
- HKEY key;
unsigned int i;
wchar_t b;
char *p;
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
