Re: Writing a Smart Card Minidriver (on PKCS#11)
- From: "Jan Spooren" <jspooren@xxxxxxxxxxxxx>
- Date: Sun, 29 Jul 2007 22:17:53 +0200
Hi Alex,
As a lot of full CSPs are based on PKCS#11, I want to use our PKCS#11 in
the
minidriver.
I wouldn't really say that a lot of full CSPs are based on an underlying
PKCS#11 library. My experience is that it's a lot easier to write a CSP
that directly sends APDUs to the smart card using the smart card API, than
trying to map a PKCS#11 library model onto the entirely different CSP model.
I read the Minidriver Specification, but there were some
functions like Challenge Response authentication or writing files which
are
not supported by PKCS#11. We only want to use the cards for certificate
authentication and signing (e.g. outlook, website authentication, logon)
and
roll out certificates with certsrv but not to store user data on them.
You don't have to support the challenge response authentication, which is
used for administrator 'log on' to the card. However, you won't be able to
e.g. use the pintool.exe tool to unblock a card if you don't have
challenge/response authentication.
You don't need to have a file system physically on your card, however your
smart card minidriver will have to emulate one. E.g., the card ID will be
read from the \cardid file and the container map file (mscp\cmapfile) will
link key container names to key numbers. Your minidriver can translate a
CardReadFile() call for the \cardid file into an APDU that retrieves a
unique card id from the card and then retrurn the card id to the caller,
without the need for a file to actually exist on the card.
Has somebody experience with a minidriver based on PKCS#11? Does this work
or are there major problems expected.
It's probably doable; but I wouldn't do it. My guess is you'll lose a lot
of time and encounter a lot of frustration trying to map 3 different
cryptographic token models: (1) the model implicitly assumed by the
minidriver model, (2) the PKCS#11 model and (3) the actual architecture of
your smart card and its APDU command and feature set. Also, you're bound to
be doing some hacks to make those models match, which will negatively affect
the security and maintainability of your solution.
To check which function of the minidriver the applications are calling
with
the parameters, it would be useful to debug a minidriver. How can I debug
it?
Is the driver running in kernel mode or can I debug it like a normal dll.
How can I debug during logon? Do I need to debug in kernel mode with 2 PCs
and a serial cable, or is there a more convenient way?
A smart card minidriver works entirely in user mode. You can debug it using
a normal debugger. The application that uses the cryptographic functions
will be calling advapi32.dll, which in turn calls basecsp.dll (the Microsoft
Base Smart Card CSP), which in turn calls your minidriver, all in user mode.
Debugging during logon using a live debugger is not possible as far as I
know. However, you can always write logging traces to a log file and
examine that. In my experience; this is sufficient to debug smart card
logon sequences.
Cheers,
Jan.
.
- Follow-Ups:
- Re: Writing a Smart Card Minidriver (on PKCS#11)
- From: Alexander
- Re: Writing a Smart Card Minidriver (on PKCS#11)
- References:
- Writing a Smart Card Minidriver (on PKCS#11)
- From: Alexander
- Writing a Smart Card Minidriver (on PKCS#11)
- Prev by Date: RE: CryptVerifySignature failing with bad_signature error
- Next by Date: Machine policy registry keys
- Previous by thread: Writing a Smart Card Minidriver (on PKCS#11)
- Next by thread: Re: Writing a Smart Card Minidriver (on PKCS#11)
- Index(es):
Relevant Pages
|
