Hello David,
[EMAIL PROTECTED] wrote:
> I wish to know if exists an implementation of the
> FileAccessCardService for the Gemplus Smartcard GemXpresso
> because I need to store certificates in it.
Not currently.. and I don't think there will ever be.
Actually, I don't really see why you would need one...
If you need to store certificates into a GemXpresso card,
you can either:
- use a pure Object Oriented approach and design/develop an
applet that serves your needs, e.g., do crypto functions,
store and retrieve data, etc.
Then you do not need any implementation of the FileAccessCardService
interface but instead you need to be able to communicate with
your applet and use it: in this case, I would suggest to use DMI
(see below for more details).
- use the javacard framework where classical ISO7816-4 files can
be emulated by Javacard objects and store your information in
these files.
This, I think, is reserved to a legacy application where you
already have an application dealing with cards and this
application *requests* that specific APDUs should be used and
that data should be be mapped on specific file identifiers.
In this case it is true that you will need a CardService that
implements the FileAccessCardService interface. But in this case,
you probably already have an application that talks to a file-based
card through such a CardService, and so if you want to fully
emulate the previous card with a GemXpresso (including which APDU
is used to launch which command), then you can use the same
CardService!
To summarize, if you have a legacy card to emulate, you should
already have the legacy application on the other side, but if
you are starting from scratch and want to use Javacards, I really
suggest to use the full power of Javacard, i.e., to use pure Java
objects and use CardServices that are dedicated to communicating
with them.
Now, how to use GemXpresso cards applets within OCF is an other
issue... :-). My answer will be twofold.
Firstly, the next version of GemXpresso RAD will be based entirely
on OCF, not anymore on a proprietary Java API. The product is not
out yet though (and I don't know the scheduled date, please contact
the Gemplus sales department for more info).
Secondly, we (at the research group) have developed some kind of
"bridging" CardService that allows to use DMI proxies inside an
OCF environment. It can be useful if you own a GemXpresso I RAD
and cards and would like to have OCF CardServices that can
communicate with your applets.
For those who are not familiar with the DMI technology (Direct
Method Invocation), it is basically similar to the classic Java RMI:
When you develop a Javacard card applet, you separate its interface
in the Java sense (i.e., what services are available from the applet
for a distant application on the client side) from its implementation.
Then the GemXpresso RAD will automatically generate a "proxy" object
on the client side that implements this interface and will be taking
care of all the communication stuff with the cards (through APDUs).
For the client application, using a Javacard applet will then be
as simple as sending messages to a pure Java object (the CardService)
on the client, no coding in APDUs is necessary anymore nor is the
development of a "process" method in the card. For more information
on this technology, please read an article by Jean-Jacques Vandewalle
and �ric V�tillard that was presented at the CARDIS'98 conference:
``Developing Smart Card-Based Application using Java Card''. An on-line
version is available on our web site at the following URL:
http://www.gemplus.com/smart/r_d/publications/art1.htm
In the new GemXpresso RAD version, OCF CardServices will be
automatically generated (i.e., they are what I called proxy objects)
With the bridge that we have developed for the first GemXpresso cards,
you will have to take the generated proxy and change a few lines: the
import lines, and the fact that it will now inherit from
"GemXpressoCardService". All the rest of the generated code should
work as before, except that you will use the OCF framework to access
the card (and so be portable on Unix, possibly use pure-java
CardTerminals, etc.).
We intend to distribute this Gemxpresso I OCF bridge on the
developer's web, but we are waiting for some authorizations (we
have to also distribute the Javacard framework exceptions class
files on the client side or else change our code to throw only
one type of exception with the code as an int).
As soon as we have some news for one way or the other and as soon as
we have the package available on the web, I will post an announcement
in this mailing-list.
> If not, could somebody tell me how to develop it? or if exists a
> guide that explains the correct manner for making it, where is it?
I would say that the best way is to start by the on-line documentation
that can be found at www.opencard.org, especially the ``Opencard
Framework Programmer's Guide Version 1.1'' which is the best place
to start.
Hope it helps. Sorry for being a bit long.
Cheers,
Christophe.
= That depends on what the meaning of the word "is" is --Bill Clinton =
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
