Re: MUSCLE check for pinpad

[Christophe Muller]

Hello,

Erwann ABALEA wrote:
> I don't think that the current release of the PC/SC standard
> supports card readers with 'expansions', like PIN pads, screens, etc.
> 
> Maybe the next version of the standard?

When OCF was split into "core" and "opt" parts, it has been decided
to move this functionality into the "opt" part. It allows to add
optional code to a reader's driver in case it has screen and pinpad.
In Java it's then pretty easy for an application to ask "does this
driver support this specific abstract interface?".

For having a look at the optional features see:
http://www.gemplus.fr/developers/technologies/opencard/doc/apidoc1.2/opencard/opt/terminal/UserInteraction.html

The "Package" link in this page points to the other optional interfaces
for readers: Lockable (to lock a multi-slot reader), PowerMangement,
and TerminalCommand which allow to send raw bytes to a reader and thus
to develop proprietary drivers that can access memory cards (the
problem with memory cards are that there is a standard but most of
the cards follow proprietary specs).

Food for thought for the new versions.. :-)

Cheers,
Christophe.

 = Before I refuse to answer your questions, I have a brief statement. =
 =-- Ronald Reagan =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE BOUNCE from [GAP ] (fwd)

[Christophe Muller]

Hello,

Taylor wrote:
> 1. Is it true that I can port driver on linux to SunOS?

I can't see why it shouldn't be possible. The MUSCLE API
will be unchanged (IFD Handler), however the way you access
Serial communication ports with the OS SPIs might vary.
I'm not a specialist neither on Linux or SunOS so I can't
tell you if it's easy or not! (The more different the SPIs are,
the harder the port.. :-)

> 2. Are all readers available for same or different platform
>(such as Windows, SunOS) of the same instruction set
>and instruction format
>(such as "power up", "power down", "send param1")?

>From the reader's point of view, it makes no difference whether you
are using it from Sun, Windows or Linux, the commands are the same
and the part of the driver dealing with the reader OS is the same.

In fact, it is even possible to write a portable driver in Java
(see our OCF CardTerminal in
http://www.gemplus.fr/developers/technologies/opencard/)
because the javax.comm API provides the necessary abstraction to
use serial ports in a portable way across OSes.

Hope it helps.

Cheers,
Christophe.

 = The Free Software Movement, was founded in 1984,   =
 = but its inspiration comes from the ideals of 1776. =
 =   --Richard Stallman (22 Feb 2001).=
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

MUSCLE [Fwd: [OCF] CFP : Gemplus Developers Conference]

[Christophe Muller]

Hello,

I forgot to forward this call for papers.. It might of interest
for some of you.

Cheers,
Christophe.

= Brasington's Wisdom: When a programmer commits to a completion date,=
=  make sure it includes day, month, and year.=



>
>
> Please find the URL of our Developers Conference Call for Papers
>
> http://www.key3studios.com/gemplusworld/call_for_papers.cfm
>
> Regards
>
> Pierre Paradinas
> Gemplus Labs
>


begin:vcard 
n:Pierre;Paradinas
tel;fax:33 4 42 36 55 55
tel;work:33 4 42 36 58 12
x-mozilla-html:FALSE
url:http://www.gemplus.com/smart
org:GEMPLUS;Research Lab
adr:;;BP 100;13 881 Gémenos;;;FRANCE
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard

OCF on Solaris (was Re: MUSCLE)

[Christophe Muller]

Hello,

Erik Pettersson wrote:
> Not sure if this is the right list to ask this question on, but here
> we go...

No it's not ;-D, this list is for questions about the MUSCLE
middleware, and there is an OpenCard list (indications on how
to subscribe can be found at http://www.opencard.org/ ) concerned
with OCF midleware questions. Now you are lucky that some people
are reading both ;-).

> I'm trying to install OCF1.2 and the Towitoko ChipDrive reader on an
> Solaris 8 server.
> What I need to know is how the configuration files
> (opencard.properties and reader.cfg)

I do not know about reader.cfg, as this is not standard in OCF..
you should look at the Towitoko CardTerminal's documentation
or sources for more details about this one. Now, for the
opencard.properties, I guess it should look like:

--
OpenCard.services = opencard.opt.util.PassThruCardServiceFactory
OpenCard.terminals =
com.gemplus.opencard.terminal.GemplusCardTerminalFactory|myreader|GCR410|/dev/ttyS1
OpenCard.trace = opencard:4 com.ibm:4 com.gemplus:4
--

just replace GemplusCardTerminalFactory by the right name,
e.g., TowitokoCardTerminalFactory (to be checked of course)
and /dev/sttyS1 by the right device name for your serial port.

Under Solaris, they used to be called /dev/ttya and /dev/ttyb
but maybe they are in the form of sttyS* now, like under Linux;
check by looking in your /dev directory.

Hope it'll help.

Cheers,
Christophe.

 = If I had more time, I would have written you a shorter letter. =
 =   -- Mark Twain.   =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE Reader driver for Java?

[Christophe Muller]

Hello,

tailorw-ncl wrote:
> I'm trying to develop a general, pure Java terminal,
> but the problem is, according to the support of java
> communication API, I can only use reader of type that
> uses serial port(such as Gemplus GCR410 reader), is
> there any solution that I can use other type or reader,
> such as USB type or the type support PCMCIA interface?

 o "Pure-java"

In fact, Java will always call some JNI/C Code at one time.
We call "pure-java", some code that is portable, for example
the GCR410 OCF CardTerminal is pure-java, because, thanks to
the javax.comm API, it is the same code that is running on Linux
platforms, Windows, Solaris, etc. (even JavaStations -JavaOS-).

 o "USB"

For USB readers, you need first to have a standard Java USB API,
so that the work of dealing with low-level OS details can be
implemented in a separate provider (like Comm providers for
the javax.comm API).

There is not yet such a standard API, but it's in the pipe..
I found that there is already:

 - a Java USB API that runs on Linux and is Open Source (but not
   "official"):

http://jusb.sourceforge.net/

 - and a JCP (Java Community Process) working group lead by IBM
   is officially in charge of defining the USB API for Java:

http://java.sun.com/aboutJava/communityprocess/jsr/jsr_080_usb.html

   A draft of specs should have been issued in October (I haven't
   checked recently but in the JSR they were referencing the open
   source work so I'm wondering if these are not actually the same
   guys...)

So, when the JCP working group is issuing the spec, the CardTerminal
implementers will be able to start working on portable drivers
for USB readers...

 o "PCMCIA"

For PCMCIA readers, I know of no attempt to define a standard API!
The fact is that this kind of device seems to make sense only
for Windows and Linux platforms so it might not be so important
to have pure-Java (portable) code (?). I have in my basement some
Java code for the Gemplus PCMCIA reader (GPR400) which is calling
C code; but it works only for Windows, not for Linux (it was
contributed by somebody from Sun). If you are interested, I can
send it to you. Now what we usually advice concerning PCMCIA, as
there is no Java API, is to use the PC/SC CardTerminal and a PC/SC
driver. The PC/SC CardTerminal has been ported to Linux by David
and is available on the MUSCLE web site. It's probably the best
solution IMHO.

Hope it helped to clarify...

Cheers,
Christophe.

 = Before I refuse to answer your questions, I have a brief statement. =
 =-- Ronald Reagan =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE About Smart Card APDU Command Processor

[Christophe Muller]

Hello,

tailorw-ncl wrote:
> Will there be any build-in "Command Processor" inside every card
> (Smart Card or Java Card), and this "Command Processor" I meant
> is responsable for deleting applet, manage card environment
> and runtime evironment, get(set) environment Parameters...
> 
> or there is a standard set of APDU command for every Smart Card
> to manage a Card(Application) environment?

No, there is no such thing, to my knowledge of course. I know of
three "families" of multiple application cards: JavaCards, MULTOS,
and Windows for Smart Card. Each of them follow a different scheme
for managing applications (or applets). In JavaCard, it's even
worse as the standard does not even define APDUs for installing/
listing/removing applets, so in the first versions, they were all
propriétary; now all new JavaCards that I know of follow a set of
specifications named "Open Platform" originally designed by Visa and
adopted by the entire JavaCard industry. That leaves you with three
different management scheme...

What we have done in OpenCard Framework, a Java middleware to access
cards, is to define a generic API for managing (installing, etc.)
applications on a card and so the application can call this API for
different types of cards. It will work of course only if the relevant
provider exist for the actual scheme. More details about this API at:
http://www.opencard.org/work/rfc-11-1/rfc-11-1.html (see the interface
named "AppletManagerCardService").

Hope it'll help.

Cheers,
Christophe.

 = "If there is a better solution... find it." -- Thomas Edison =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE pcsc and opencard

[Christophe Muller]

Hello,

Michael McCabe wrote:
> 
> I'm new to all this and was wondering what the main differences
> between PCSC and OpenCard are. Are they both middleware that provide
> the programmer with an API?

Basically yes, they are both midleware that helps the programmers
access and use smart cards. OCF is more dedicated to Java applications
and MUSCLE to C applications although by using RPC or CORBA, both
could be used by any type of language.. (see for instance Solaris 8
in which Sun has integrated an OCF server that can be accessed
-through RPC- by a PAM module).

Common points: both are Open Source and even free software (for those
who care), MUSCLE is GPLed and OCF is distributed under a BSD-style
license.

Differences: OCF design is closer to the idea of framework (see
Taligent whitepapers: http://www.ibm.com/java/education/oobuilding/ )
while PC/SC is more a set of API. OCF has been designed from the
very beginning with a strong focus on high-level APIs while the MS
PC/SC's first goal was to have a uniform API to access card readers,
just like we have one for CDROMs. MUSCLE will probably go beyond
that and introduce card services APIs but MS does not seem to be
very interested in that..

E.g., in OCF, you have APIs not only for communicating APDUs through
a reader to a card, but also APIs for using ISO7816-4 file-system based
cards, ISO7816-7 database cards (with a possibility of using JDBC),
crypto APIs (signature, key generation, key import, etc.), EMV cards,
and APIs for managing applets on a card. We are also working towards a
deeper integration with JCA/JCE standard Java APIs.

Whether you need a more simple API for communicating with a card,
or a more complex framework that will be flexible and extensible
when new needs arise can guide you. Also MUSCLE is now available
in Unix, MacOS X, and OCF anywhere you can find Java (Unix, MacOS X,
but also Windows whatever, OS/2, AS400, and even small devices: there
is a special version named TOCF for embedded devices).

Last point. You can use OCF CardServices (i.e., code that know
how to use a specific type of card) with MUSCLE drivers (i.e., code
that know how to use a reader) by using a wrapper called 
PcscCardTerminal that was ported by David to MUSCLE.

Hope it helps. You'll find more details at MUSCLE and OCF sites.

Cheers,
Christophe.

 = It's .net as in the net that people are caught in if they =
 = use it, correct?  -- Greg@b3f(b)log1000   =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE GCR410 and memory card

[Christophe Muller]

Hello,

R & D - REALTRONIC wrote:
> 
> Hello,
> I would like to use the Gemplus GCR410 reader
> with memory card (I2C and Siemens SLE4418/28).
> The PCSC driver for muscle works only with the T=0 and T=1
> protocol. Is there anybody who have already used the GCR410
> with memory card ? or have already write the missing code ?
> 

Actually, it is possible to use a GCR410 to access memory cards.
What you need is to have a mean of direct connection to the reader
in order to use GemCore features to access memory cards. I know that
in OCF (java environment), such a function is 'sendTerminalCommand'.

I asked the PC/SC experts that I know of here (I put them in Bcc
if they need to add more info) and they told me the equivalent
function in PC/SC is 'SCardControl'. The problem when you use such
direct access function is that the code is proprietary because
the code sequence to send to the reader is not standardized.
So with the Windows PC/SC, it is actually possible to use the
GCR410 and the 'SCardControl' function to access memory cards.

The bad news, in case of Linux, are that:

1) this function has been documented on the driver side but my PC/SC
experts didn't find a corresponding API of the resource manager
(in the pcsc-lite 0.7.3 pdf) that could actually be used by the
applications. David, any thoughts on this? Does this API exist?

2) contrary to what we have done in the Windows driver, this
memory card access has not been implemented in the GCR410 Linux
driver, so you would have to look at the GemCore specifications:
http://www.linuxnet.com/documentation/files/e5225050.pdf and then
update the driver sources in order to enable this feature.

Hope it'll help a little. Good luck anyway.

Cheers,
Christophe.

= I assure you, Mrs. Buttle, the Ministry is very scrupulous about=
= following up and eradicating any error.  If you have any complaints = 
= which you'd like to make, I'd be more than happy to send you the=
= appropriate forms.-- Sam (Brazil)   =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE script engine

[Christophe Muller]

Hello,

zhuangyy wrote:
> can any one suggest me a open source, powerful and flexible
> script engine available for use.
> 

All opinions below are mine. They might .. I mean *will* not match
the other people's ones I'm sure ;-D, but at least I provide the
pointers, you can download, learn, and try them for a couple of days
(a couple of month for Perl! ;-), then maybe post your thoughts.

Anyway, here is my list, from "recommended" to "to be avoided":

--- TCL ---

I would suggest to use TCL (Tool Command Language)
see :
http://dev.scriptics.com/

TCL is Open Source, very simple to learn yet very powerful (some kind
of Lisp semantics with a C/Bourne Shell syntax); for new users of your
engine, its syntax makes it very simple to learn. Furthermore, this
langage has really been designed for buidling scripting engines
"arround" a given functinality that has C bindings, for example Tk is
a graphical toolkit built arround X11 (or Mac toolbox, Windoz, etc.
it has been ported), other popular (Open Source) extensions include:
database access, crypto algorithms, pilot of interactive applications
(expect), network management (SNMP etc.), LDAP, SSL, etc. there are
dozens of them. There are also several OO extensions to Tcl, the
most famous being [incr Tcl] (will be integrated in the next version)
See http://dev.scriptics.com/resource/software/extensions/ for more.
Tcl also has a strong community, newsgroups, etc. Tcl's license is BSD
style, like most of its extensions.

If you are going to provide scripting functionality arround a C API,
it's a breeze with Tcl !

Other bets could be:

--- GUILE ---

 - GUILE (Guile is the GNU extensibility library)
see :
http://www.gnu.org/software/guile/guile.html

Like TCL, GUILE has also been designed from the very beginning
to be an extension language, to build scripting engines inside
your applications. It has roots in the Elisp engine found inside
the Emacs editor, but has different (and more advanced) technical
characteristics: Elisp is a small lisp-like, while Guile is based on
Scheme; also it lets your users choose between different syntax: lisp,
Scheme, Tcl, Python, etc. that will be translated into scheme.

Guile is of course under GPL.

--- PYTHON ---

 - Python is OO and has a weird syntax to my opinion (indentation
is significant) but has a lot of admirers, probably the best
choice if your application is going to be 100.000 lines long and you
need to design good modular libraries, frameworks or applications.
see:
http://www.python.org/

Python is Open Source, its license is (in my view) BSD/X11 style.

If you want to read more detailed and serious (?) review than this
poor mail, have a look at this page:

http://www.python.org/doc/Comparisons.html

they have pointers on articles comparing and characterizing scripting
langages such as Perl, Tcl, Python (of course), Lua, Java, Rexx,
Scheme or Lisp. Maybe more biased towards Python, but that would be
interesting for you. Try to type a few "hello world" to make your
own opinion too :-). 

--- PERL ---

 - Perl is very good at working on texts but its learning curve is
a bit steep I think, also I'm not sure how simple it is to
implement a new module making native calls to C (I know that in
Tcl and Guile it is very easy and in Java, it is.. a hell ! ;-D).
However, Perl is probably the language with the biggest library
of Open Source modules (most of them in pure Perl), except Java maybe.
see :
http://www.perl.com/pub

Perl license is "Artistic", fully Open Source.

--- MISC. ---

 - Rexx, etc. I would suggest to stick with a language with
a big community, maybe not the biggest, but a minimum is
required. I have spend 2 years suffering on LeLisp, a french
proprietary dialect of Lisp, used by nobody in the world, and
then 7 years being helped and having fun with the Tcl community.
Guile (GNU people), Tcl (12 years old), Perl, and Python are ok,
but beware of anything "less mainstream", that's an advice. Very
unfortunately, same goes for C/Java vs Eiffel/Ada/Modula3, etc. :-(

 - Also, I would rather avoid interpreted Javas out there, such as
BSH, the BeanShell, which is very good for people working in Java
(like me) but is also very slow and was not designed for building
scripting engines, more to allow Java programmers to develop "the
interpretive" way (which is very appealing).
see:
http://www.beanshell.org/

Cheers,
Christophe.

 = Nothing is faster than the speed of light ...   =
 = To prove this to yourself, try opening the refrigerator =
 = door before the light comes on. =
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Develo

Re: MUSCLE information

[Christophe Muller]

Hello,

Sergio Rdz. Parra wrote:
> 
>>> Hi all,
>>> I am looking for information about the process of generating
>>> keys - the private and the public key - in a smartcard.
> 
> I only know Gemplus smartcards. And they have one (called GPK, from
> Gemplus Public Key), that has such features. You just have to send
> a command (APDU) to create the PKI support, wich means both public
> and private part of the key.
> I hope it's useful.
> 

Also I do not have C code using the MUSCLE (PC/SC) API to provide in
Open Source, but you can download OCF GPK8000 CardServices (in Java)
and have a look especially at a class called "GPKKeyGenerationService"
that I think is doing what you want. This class allows to:

- Generate a pair of RSA keys on card,
and
- Read a public key (that was generated on the card) from the
  card.

This code is OpenSource and freely available on the web to use or
modify (see: http://www.gemplus.fr/developers/technologies/opencard/
and "CardServices Downloads").

You should be able to run it both directly using the OCF pure Java
CardTerminal drivers that exist for numerous card readers (see:
http://www.opencard.org/index-devices.shtml) or also to use it
with the MUSCLE PC/SC and one of its driver, using the bridge
between PC/SC and OCF that David has provided on the web site (see:
http://www.linuxnet.com/middleware/middleware.html).

Hope it helps.

Cheers,
Christophe.

 = FOOT: A device for finding furniture in the dark.=
--
-
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

MUSCLE [Fwd: Gemplus Developer Conference '99. Book now!]

[Christophe Muller]

Hello,

Please forgive me for using the M.U.S.C.L.E mailing-list for
announcing a Gemplus event... but as David will be talking about
M.U.S.C.L.E (and the Linux PC/SC architecture based on CORBA), and
as there are other talks about PC/SC, OCF, etc. it is also, I think,
of interest for many people here.

Attached is a message mentionning that you have only two more days to
register with a 30% discount at the "GEMPLUS DEVELOPER CONFERENCE '99"
to be held in Paris in June 21st/22nd. It includes relevant web URLs.

As I am the coordinator of Track 1 (among four tracks) titled :
"Smart Card Integration Solutions", I can give you a sneak preview
of what the program will be for this track during the two days:

Day 1:

 o Dedicated to OCF, i.e.,

- Open card Framework 1.1.1. and beyond (G+)
- OpenCard Framework Roadmap at Gemplus (G+)
- An OCF API for Database Smart Cards (CERAM Master in DB Technologies)
  (Note: this includes a connection with the JDBC java API)
- DSS SmartBeans Componentware/Toolkit (DSS)
- The OCEAN Project (IBM)
- OCF applied to a Gemplus Product Architecture (G+)
- Architecture for Point of Transactions (Dassault)

Day 2: is dedicated to other middleware technologies:

 o PC/SC (2 talks)

 o the Gemplus Card Reader API goes Open Source (1)

 o M.U.S.C.L.E and a presentation of the Linux PC/SC Architecture (1)

 o Advanced Data Management for Smartcards (2 talks) i.e.,:

- GemDB & ODBC or how to access easily to an in-card database (G+)
- Implementation of Transactional Mechanisms for Open Smartcard (Univ.
  of Lille).

I have less information about the other tracks, but I know they
focus on respectively "Information Technology and the Internet"
(including talks about PKI, E-commerce, PKCS11, XML, etc.), "Open
OS and Multi-Applications Cards" (w/ the three classics: Javacard,
Multos, and WSC), and "Wireless Communications". There are also
three keynote speakers from very important companies.

Hope to see you there!

Cheers,
Christophe.

 = Law of Research: Enough research will tend to support your theory =




GEMPLUS DEVELOPER CONFERENCE '99
June 21-22, CNIT Paris

The first worldwide developers'conference in the smart card industry!

You have only 2 days left until May 21st to register for the Gemplus
Developer
Conference '99 and benefit from over 30% discount! Register now!
http://www.gemplus.com/gdc99
http://www.gemplus.fr/developers/gdc99/gdcreg.htm/

An exceptional opportunity you can not afford to miss:
- application tools,
- extensive technical information,
- Gemplus R&D experts and smart card developers,
- Gemplus' latest innovations and products

The definitive program will be online as from Thursday 20th, come and visit
www.gemplus.com/gdc99.

Be a Smart Developer!







 
 INFORMATIONAUTOMATIC VIRUS CHECK (GEMPLUS)   No virus known.
 

MUSCLE Interoperability (Re: Has anyone looked at ??)

[Christophe Muller]

Hello,

DAVID SIMS 1 281 285 7792 wrote:
> 
> Hi,
> 
>   There is a good web page at  regarding identity
> tokens (and the spec's for them)

Huh! I tried but I do not read swedish yet.. (shame on me.. :-).

> It seems pretty obvious to me that
> in order to have *any* application level interoperability (via PKCS 11 or
> PC/SC or OCF or CDSA or any of these device specific 'standards') that
> there will need to be a consistent file system (and contents) specified
> for the card itself independent of the mechanism through which the data
> is accessed and which cuts across all of the device connection 
> mechanisms...
> 
>   Anyone have thoughts about that???

You might want to register to the CardService working group at OCF 
(I think Tim Jurgensen is currently representing slb), because
we are working on such issues (i.e., we would like to extend the current
framework, that mostly deals with APDU sending (like PC/SC) with
application level interoperability in mind). Actually, I would not place
the four acronyms on the same line: PC/SC is a platform specific
middleware for card access. It includes a "module", CAPI, based on a
proprietary crypto API. Likewise (almost), OCF is a platform independent
framework that will include one or several modules offering
cryptographic
APIs to applications.

Both PKCS#11 and CDSA has been mentionned, and the former is likely to
be
implemented first. We can also think of providing packages to JCA that
deals with sc-based cryptographic implementations. It seems to me that
interoperability can only be achieved if, on the contrary, the
application does not know exactly where the information is stored, or
even using what kind of data structure (e.g., some cards may be
file-system based, but other will be object-based, and a third kind will
be table-based, like DBs). We are trying in OCF to hide these
differences under Java abstract classes and to prevent the data location
features from being too much bound to the file-system-based services..

Now if the data location, what IBM is calling the card layout, has to
be manipulated by the application, we can provide some kind of symbolic
names translation, each card provider will also provide the software
module that does the naming services.

Anyway, if the first set of middleware (PC/SC, first OCF) has ensured
the independence of card terminals, the future generation will also
ensure the independence of cards, but there is much more work to be
done.. :-)

Cheers,
Christophe.

 = Bloody typical, they've gone back to metric without telling us.   =
 = -- Charlie, Department of Works (Brazil)  =
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

Re: MUSCLE Kernel support for readers?

[Christophe Muller]

Hello David, Hello Opencard and Sclinux users,

David was replying to a message asking about kernel support
for smartcards under Linux:

David Corcoran wrote:
> 
> I'm working with OpenCard and PC/SC.  Of course these would run as
> daemons
> and probably have no kernel integration.  OpenCard is nice and
> extensible
> when dynamically allocating new Card Terminals (and it works with
> iButtons). Plus the work is done.

I already sent a mail to both mailing lists (i.e., users of smartcards
in a Linux environment and users of Opencard) to advocate Opencard
Framework under Linux, which could have several benefits:
 1) Opencard is free,
 2) it will allow the use a 100% pure Java solution (through the use
of Sun's CommPORT API, already ported to Linux),
 3) it is portable (developed in Java) and has a native interface
to accomodate PC/SC under a windows environment,
 4) it provides a powerful and extensible framework for the development
of smartcard-aware applications: some high-level services will be
developped in the future, e.g., for dealing with ISO7816 card files
(already exists), with Javacards (under investigation), or misc
horizontal services such as PKCS#11 (under investigation,see below).

> PC/SC is written in C and I know the man at Microsoft who wrote the
> resource manager but then there is the cryptolib stuff.  I'm working
> hard to get an open standard support under Linux.  If we use
> OpenCard - anyone out there a Java Native Interface expert ?

I am neither a specialist in JNI (I try to stay away from it! ;-), nor
in cryptolib.. what is it exactly? (Is it MS crypto API?)

The Opencard CardService Working Group is currently investigating the
addition of a PKCS#11 service, which is an open (non-proprietary) 
defacto standard for cryptographic services. A Java interface to
PKCS#11 has been presented as a work starting point at the last
working group meeting.

This interface has been developed and published by IBM on their
experimental software site (i.e., on "www.alphaWorks.ibm.com")
the 9th of April 1998. Its status is still undefined (see alphaworks
copyright/documentation for more details).

>From the Overview text:
 <<
The PKCS#11 API for Java is represented by a set of abstract 
Java classes (package com.ibm.pkcs11) that define the
interface but don't provide any functionality themselves.
The package com.ibm.pkcs11.nat provides an implementation
of the abstract classes and maps the Java API to calls to a
native PKCS#11 library. 
   >>

Maybe such an API and its JNI bindings is what you are looking for.. 
would it help if it becomes available someday in Opencard?

Cheers,
Christophe.

 = There are three roads to ruin; women, gambling and technicians. =
 = The most pleasant is with women, the quickest is with gambling, =
 = but the surest is with technicians.   -- Georges Pompidou   =
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***

OCF and Linux (Re: MUSCLE NEW CODE AND X-APP)

[Christophe Muller]

Hello,

Note: This is a reply message to the Smartcard-Linux mailing list in
which I place in carbon-copy the Opencard mailing-list. I suggest to
the Opencard people to reply only to [EMAIL PROTECTED] in order to
save the time of other Opencard members that are not interested in
the subject.
---
Jan Iven wrote:
> I think we shouldn't muck around with the serial options, either.
> stty (or the like) should be able to set everything up correctly, or
> at least lets move this into the resource manager on a
> device-by-device basis (see below), not application-by-application
> basis.

Definitely, you should have some component managing the communication
with the card terminal and it would be much better if it offers
a generic API so that multiple drivers for multiple terminals could
be plugged in but the application layers only see one API.

This thing exists in two different incarnations:

1) a windows-centric solution : PC/SC, in which a major
   component is part of the OS (and not ported anywhere
   else at this date)

2) a portable and moreover Object Oriented Framework solution
   implemented in Java : OpenCard Framework.
   (Version 1.0 has just been released April 29th 1998.)

> + After having a look at the PC/SC specs, I suggest we should aim for
>   that. [ ... ]
> I would like to see a generic API to build applications on instead of
> building them on top of the driver. There are rather a lot of
> different readers out there with only minor differences (LEDs to turn
> on/off etc), so much of the driver code will be shared. With
> the PC/SC specs already existing, we would then present a similar API
> as the "evil empire", making transition to linux as smooth as possible
> (think of all the experimental "wallets" (ultrasecure, but will only
> run under Win95..).

I would really like to point you to OpenCard before you attempt to
reimplement a PC/SC resource manager from scratch. It is very easy
to write Card Terminal drivers that will inherit from the same
abstract classes as specified by the OCF framework. As a first result,
a PC/SC wrapper has been developped that allow the use the OCF API
through PC/SC reader access. Other drivers either based on native
implementation (through JNI) or that can use a 100% pure Java
implementation (based on the new Java1.2 CommPORT API) are currently
being developped. Gemplus is investigating for its card terminals
the possibility to have 100% pure Java drivers in addition to PC/SC
which mean that they would come *for free* on Linux if CommPORT is
ported (the "muck around with the serial options" as mentionned above)
by Sun (or if they give you the sources).

Going PC/SC would only allow people to migrate from Linux to Windows
IMHO. On the contrary, going OCF would allow Linux people to write
*portable* solutions (even on Windows!, but also on JavaStations,etc.).

The OpenCard consortium manages the OCF standard to access smartcards.
It includes companies such as IMB, Gemplus, Bull, Schumberger, Sun,
Visa, SCM, etc.

Please see the OpenCard documentation at http://www.opencard.org/.

Cheers,
Christophe.

= Rule of Accuracy: When working toward the solution of a problem,  =
=   it always helps if you know the answer. =
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***