Hello,

Alan Alie wrote:
> 
> Hello again Christophe,
> 
> Thanks again for your help with my OCF/PKCS#11 questions. It proved
> very helpful in the report I had to write.

Thanks. Sorry for replying late to this message.. I CCed the
list as I think there is a similar thread on this issue.

> A third party (Company X) issues cryptographic smart cards using its
> own issuing s/w and this s/w uses a PKCS#11 API to write to these
> cards. Then we produce an application using OCF. Can we use OCF's
> SignatureCardService to access the cryptographic functions of these
> cards?

Yes you can.

But "SignatureCardService", in the opencard.opt.signature package,
is a Java *interface*, not a *class*. It is an API under which you
have either to find a CardService for the card you are currently
using, or to write your own. Currently, I know of CardServices
that implements this interface for IBM MFC cards and Gemplus GPK8000
cards. If the CardService do not yet exist for the CompanyX card,
you have to get the specs of the card (in terms of APDU commands
to send for signing, generating a key pair, etc.) and also in terms
of personalization (what is where, in which files, etc.) and then
implement your own SignatureCardService.

This is because in the domain of cryptographic services, there are
no strong standard for card commands, layout, etc. It might
come in the future but for the moment commands for GPK8000, MFC,
Cryptoflex, etc. cards are all completely different. So the best
we can do for interoperability is to define an abstract API such
as the one in OCF, and to write drivers for all the cards you want
to use (or just when you need them).

In fact, OCF goes a step further because thanks to the Factory/Registry
design pattern, the framework is able to automatically detect what
card is inserted and select the right software module (CardService)
according to what the application wants to do.

This feature of the framework allows your application to be
completely portable because you don't even have to explicitely
create an object for using, say, a GPK card, and then modify
this line if you want to switch to, say, MFC cards. What you
do in your application is to write some code that request a card
and a CardService *that implements a particular interface*, such
as the Signature  one (or FileAccess, or Database, etc.).

The application will not know what type of card and what instance
of CardService it will use. Example of code:
 ______
| 
|System.out.println ("Waiting for a signature card...");
|SmartCard sm
|  = SmartCard.waitForCard(new CardRequest(CardRequest.NEWCARD,
|                                          null,
|                                          SignatureCardService.class));
|SignatureCardService cs
|  = (SignatureCardService)sm.getCardService(SignatureCardService.class,
|                                            true);
|// [...init etc...]
|byte[] signature = cs.signData(kf, JCAStandardNames.SHA1_RSA,
|                               JCAStandardNames.ZERO_PADDING, data);
|etc.
|______

Now if you are using smart cards in a domain where there is a
strong standard, such as the GSM11.11 and GSM11.14 norms for
SIM cards, then a CardService that you write for one SIM card will
work on any SIM card compliant to the norms. This is because the
norm specifies how the card can be used (APDUs) and also where the
data is stored (PIN, AddressBook, etc.), in what form, etc.

See also the OCF 1.2 Programmer's Guide, signature generation and
verification section for more on those interfaces:

http://www.opencard.org/docs/pguide/PGuide.html#HDRSIGNATUREGENERATIONANDVER

Hope it helps.

Cheers,
Christophe.

 = Utopia would be free speech, free software, AND free beer. --Davo. =
--
-------------------------------------------------------------
[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!
-------------------------------------------------------------


---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/

! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
!                           [EMAIL PROTECTED]
! containing the word
!                           unsubscribe 
! in the body.

Reply via email to