On 03.02.2009, at 22:45, Alon Bar-Lev wrote:
> OpenSC is a great effort trying to join efforts and support as much
> devices
> as possible. The vision is great. So I fixed OpenSC PKCS#11
> implementation
> to actually work (fork(), plug&play etc...).
We should look at the broad picture of cards, readers and applications
and see what different projects try to achieve and have to offer. I'll
explain my functional, opinionated POV:
* PC/SC(-lite) (with CCID) - access to readers. _THE_ API for cross-
platform access, implements support for most card readers, including
new, hopefully finally uniform features in the CCID spec like pinpads.
* OpenCT - access to readers. Only on *nix and mostly for USB tokens
which don't have pcsc-lite drivers. Contains a limited CCID driver
which conflicts with pcsc-lite which is not nice. Also contains a
plugin for pcsc-lite to use OpenCT readers/drivers with pcsc-lite.
* CT-API - reader manufacturers provide these drivers for some reason,
but those drivers do provide access to some reader features not
available via previous systems. Only really exists on Windows/
specialized solutions and just as you have to "fix and configure"
PKCS#11 modules into software you have to configure CT-API drivers
into OpenSC...
This covers readers. I don't have any strong opinions about the
reader layer except that I want to talk PC/SC from API point of view
and that pinpads (and displays and probably also contactless cards/
readers) actually matter. That's one reason why there are CT-API
drivers out there I guess. The odds might be 80/20 for PC/SC here.
Then we have cards and the software inside the cards. I don't know
contact-less technology, but basically the division is: Java and
other. This is where OpenSC steps in.
* "Muscle scene"
1) used to be the umbrella project for pcsc-lite + reader drivers
(I would say the project name is now obsoleted because of pcsc-lite
and CCID driver?)
2) an applet for Java cards and utilities (globalplatform) for
javacards + pcsc to "write" onto Javacards
3) a PKCS#11 interface to talk to that applet on a JavaCard.
* OpenSC
1) provides card drivers for various cards
2) provides tools to initialize those cards with PKCS#15 compliant
structures (pkcs15-init)
3) contains a bunch of read-only drivers for "not-compliant" cards/
applets (pkcs15-syn)
4) has a PKCS#11 module to expose whatever is on a supported card,
no matter how it got there (with pkcs15-init, with a muscle applet or
from a government office).
For a possible distribution of users see below. What is important here
is that OpenSC includes a lot of code to read from various card
formats and allows to write cards in one format (pkcs#15)
Then there are applications. I divide them as:
* "smart card applications" - contact-less door opening? Root
partition encryption? These (specialized) applications know the fact
that they are dealing with smart cards and probably have some specific
requirements for their interactions.
* "applications doing crypto". Firefox doing SSL, OpenVPN doing RSA,
GnuPG or SSH doing its thing etc.. These are applications that Alon
has extended to support PKCS#11.
The first class of applications do some scary tricks to get their
things done and usually use whatever API/solution that they feel is
appropriate and available.
The second class of applications should be implemented in a way and
with APIs that allow application developers to "forget" the location
of the private keys - be it plaintext (or password protected), full-
blown HSM or some USB token. Two platforms, Windows and Mac OS X,
provide solutions and high level API-s (like open_url as used by some
web toolkit actually using your inserted smart card for https pages if
required) for application developers, whereas the fragmentation of
*nix looks as spaghetti as OpenSC itself.
- Windows: win32 API-s which use CryptoAPI (+PC/SC based CSP-s) for
crypto if needed, PKCS#11 for applications that need to expose the
fact that they use PKCS#11 to the user (like Firefox. Actually there
is a module in Mozilla CVS that bridges Mozilla's NSS with CryptoAPI)
- Mac OS X: high level API-s which use CDSA/Tokend (which is a card
driver + PC/SC) for crypto if needed, PKCS#11 if implemented by
application
- Linux and the rest: PKCS#11 if implemented and configured, OpenSSL
+ engines (engine_pkcs11) if implemented and configured, QCA if
implemented and available, direct PC/SC if available, direct
ifdhandler if available ... the list could probably go on
Last time I checked, QCA was the most promising on *nix. But then
there are Gnome apps and console apps and ...
Finally we have users who have cards and readers and want to use them
with some applications. They are divided into two groups again:
* Users who discover a card from their pocket and want to use it for
something
- Read only cards for SSL (With EU countries already having (tens?)
of millions citizens with capable eID cards and more coming and work
being done for e-government, banking etc, this is not a small use case)
- read the phonebook of a GSM sim
* Users who buy smart cards for fiddling with them - this is writing
stuff onto cards.
- for private consumption ("onepin profile")
- for organization-wide rollout ("sopin profile" with some PKI/CA)
Now, for catering user needs I believe the second group is more likely
to find OpenSC and have a card reader or know what PKCS#11 means and
how to deal with it, yet there are more people out there with smart
cards who would use them if possible.
I guess 80% of the total card-capable population just have a card in
RO mode they would like to use. Most probably they could end up with
OpenSC and some card driver.
If we talk about restructuring or "smoothing" the scene, we should
really figure out some bits and pieces in the big picture and how they
fit/should fit together to find the most rewarding locations to
improve. Even if we revolutionize the low level things but the
goodieness never reaches a news reader so that it could seamlessly
fetch RSS over HTTPS with any reader and any card supported by open
source, maybe it's really not worth it?
> Then I needed OpenSC work on Windows so I rewrote the build system
> and added mingw32, mingw64 support. Now we can use single build system
> to all platforms.
Mingw and the new build system is really nice but from Windows point
of view, it is a secondary way of building software for Windows. I'm
not telling that the current win32 build system is any good, but under
some circumstances it actually does produce a windows binary. mingw/
auto*/libtool stack has artificial limitations as well (such as static
linking). The best way is still to go with native tools.
> We have much work in OpenSC, mainly remove the one application session
> limitation (stateless mode),
Cards have their own state, applications have their own state, which
can depends on the internal state of the card. The description you
gave to the stateless mode some time ago forgets about pinpads and
would make my pinpad reader beep for every new HTTPS window I open in
Firefox. PIN cache in OpenSC (PKCS#15/PKCS#11 layer) needs to be re-
factored, but you can't build the stateless architecture on the fact
that you can keep a PIN somewhere and re-play it to the card on every
transaction. Keeping the state in sync needs to be worked by every
card driver, as cards have different capabilities and features (some
reset access rights if you change a directory, some don't etc)
> adding EC as RSA/DSA depreciated.
I don't believe that 4096 RSA will be deprecated in next 2..3 years.
But hell knows, I'm not a cryptanalyst. EC support is 5+ of course.
> I estimate there
> is a one man year at full time job in order to make OpenSC viable
> alternative to
> commercial products.
>
> I found that if we can reduce the number of reader framework OpenSC
> support
> it would be easier to support slot events (example).
>
> So why should OpenSC support OpenCT, CT, PC/SC? If there was a
> good reader framework we can reduce it to a single application API.
CT-API is deprecated by nature but in real life there are several
manufacturers providing drivers in this form, and some things that
only work properly via CT-API (like pinpads/displays).
I don't think it hurts to have the support there for those who want.
> I don't wish to let the option of having a free open source
> alternative in
> the cryptographic devices world die. If we don't provide good
> infrastructure
> we let this die.
> As Andreas said, OpenSC is in decline, and pcsc-lite project maintain
> only single CCID driver. Joining forces is the only way we can give
> this another chance.
Before CCID there AFAIK was no real standard for readers. These days
there are not that many readers that are NOT CCID.
I would not say that OpenSC is in decline, I know for sure that OpenSC
based code is used by (tens of) thousands of people in Estonia alone
and other EU countries as well.
Talking about revolutions - last time it "happened" OpenSC was split
into different packages...
cheers,
--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
