OpenCard Introduction & Overview

a Framework Approach to Smart Cards Services

CTST 2000

Abstract:

This whitepaper intends to give an overview of the goals and purpose of OpenCard Framework (OCF). As detailed descriptions of the OCF functionalities and architecture can be found in many documents, we will first detail why we think the smart card industry needs a framework approach and a standardized open source middleware.

Available on-line information about the OpenCard Framework includes:

• A gentle introduction to the OCF concepts, ``OpenCard Framework - General Information Web Document'', see [13],

• A white paper by Reto Hermann and Dirk Husemann that gives more details on the internal principles of the framework, ``OpenCard Framework'', formely ``OpenCard Framework 1.0 White Paper'', see [15],

• An article comparing two approaches for smart card access middleware: PC/SC [20] and OCF, by Matthias Kaiserwerth, ``The OpenCard Framework and PC/SC'', see [16],

• At last, a detailed programmer's reference documentation that explains how to write applications that use OCF, and also how to write OCF components for readers or smart cards, ``OpenCard Framework 1.2 Programmer's Guide'', see [14].

So before describing the OpenCard architecture, we will describe what we should expect from a middleware designed for smartcard-aware applications (types of components, requirements, etc.) and present the framework approach.

1.1 Smart Card Applications

Applications that are using smart cards are in two parts: one part is running in a card, and the other one on a terminal or a server.

These applications are usually very difficult and complex to program. Most of the time, control codes of the card reader are proprietary and card commands too. They are also usually using some very low-level OS-dependent serial APIs. At last, the smart card commands and communication protocols (T=0, T=1) are low-level.

For all these reasons of complexity and proprietary nature, the learning curve for application developers is steep!

1.2 Smart Card Standards

This section provides a very brief overview of standards related to smart cards.

Standardization has been very important for the growth of the smart card industry. Like in other industries (e.g., telecoms), precise definitions of dimensions, protocols, commands, etc... have contributed to the wide acceptance of smart cards among many different vendors (card providers, reader providers, application developers, client developers, etc.).

From time to time, well accepted standards need to be updated, extended, or redesigned as technology evolves, requirements also, and they are not sufficient enough anymore for the new requirements to be fulfilled.

Hence, if strong standards at low levels of protocols are necessary to ensure a first interoperability and launch a new industry (e.g., OSI model, TCP/IP), they are at one point not sufficient anymore for solving needs, because they are not flexible at all (i.e., something that has been forgotten cannot be added without great difficulty).

Some more dynamic models (e.g., ODP model, see [6], CORBA, see [7]) that allow both interoperability and flexibility become necessary. They are usually based on techniques such as gateways (or proxy objects), meta data, or preprocessors. In the smart card world, we obviously are still in the OSI model phase, as each new domain-dedicated standard defines new named protocol packets (APDUs) as new strongly-standardized commands.

We can divide smart card standards in three categories:

• Horizontal Standards "in the card", i.e., smart card OS standards (e.g., data structures, file systems, object systems, commands), or communication standards (e.g., identifications -answer to reset-, messaging methods, protocol, etc.). Examples of this type of standards are:

  • ISO/IEC 7816: ISO standard for ICCs with contacts [10]

  • ISO/IEC 10536: ISO standard for ICCs without contacts

  • Java Card[Tm] 2.1: standard for Java Applets running in a smart card

• Domain-Specific or Vertical Standards (standards of business-specific services). Examples of this type of standards are:

  • EMV 2.0 : Europay, Mastercard, Visa standard for payment smart cards

  • GSM 11.11, 11.14: Mobile phone standard for SIM cards and SIM Toolkit

  • Mondex, Proton, etc.: Digital cash standards

  We will, on the opposite focus on the following type of standards:

• Horizontal Standards "outside the card", i.e., standards of generic security services APIs or middleware environments. Examples of this type of standards are:

  • PKCS#11: Cryptographic Token Interface Standard [11]

  • CDSA: Common Data Security Architecture: an open security infrastructure from Intel

  • PC/SC: C-based card access framework for Windows95/98/NT applications (and now Linux/Unix, see [22])

  • OCF: Java-based card access framework for Network computers (and many other platforms!)

Note that ISO has not yet standardized any access API: this is not necessary as soon as protocols are well defined: any application, written in any language, conforming to the ISO7816 protocols will be able to interoperate with a smart card! The problem is that communications with smart card readers is not yet standardized, leading to specific application code or waste of time in portability. In fact, a smartcard-access environment is not fully necessary, it would however save time and money: this is why frameworks are interesting.

In many other situations a framework can help the smartcard-aware application developer, e.g., when he/she wants to write an application that can interoperate with different smart cards offering the same functionality, but that have different proprietary APIs.

The next sections will describe what is an Object-Oriented Framework, what model of framework we can suggest for smart card middleware, and what are the requirements for this type of software.

1.3 A Framework Approach

In this section, we introduce the Frameworks technology and draw a draft of smart card framework model.

1.3.1 What is a framework?

In [3], Booch gives a good definition of Frameworks:

``` A framework is a microarchitecture denoting a collection of classes and mechanisms that together provide a set of services for a particular domain, which clients can use as well as adapt. We distinguish a framework from a simple class library by the fact that frameworks generally have control mechanisms that the framework calls client operations. In a class library, it's usually the reverse: Clients mainly invoke operations from the library. Thus, a framework is a kind of pattern that provides reuse in the large.''

As we can see, frameworks (see also [1], [2]) are like templates: they save time by providing some already existing classes or interfaces, thus enabling application programmers to develop more quickly by either using or extending the framework and following its guidelines and coding/naming patterns.

1.3.2 A Smart Card Framework Model

This paragraph describes a simple layer model for smart card frameworks. It is somewhat inspired by the ODP model, although a lot simpler!

First, we can define three different interworking levels, each of them being based on a different paradigm (objects, language, and communication), each of them addressing different needs, and manipulating different entities. Figure 1 shows how some components (e.g., C1, C2, C3) of our system will use the three levels.

  

Figure 1: Interworking Model

Decreasing levels of abstractions, represented by the three layers, can be defined. These levels are: the Object Layer, the Programming Layer, and the Communication or Transport Layer.

• The Object Layer: Components defined at this level are based on Object-Oriented paradigm. A description formalism could either be an Interface Description Language (IDL) like in ODP [6], CORBA [7], or DCOM, or could be just regular Java Interfaces. The naming is high-level (e.g., Naming Service),

• The Programming Layer: Although many more layers exist in OSI, in the smart card world we usually access smart cards using an ISO-standardized language. Components defined at this level are based on a given language: e.g., 7816-4 file system procedures, or 7816-7 database procedures, or domain-dedicated procedures (e.g., GSM 11.11). The description formalism does not have to be language-independant, because the manipulated entities are standard APDUs. The naming approach relies on the language designators (i.e., procedures identifiers) as defined by the standards.

• The Communication Layer: Components defined at this level are also based on the ISO-standardized smart card protocols (7816-3/-4). Manipulated entities are TPDUs. No naming approach is necessary because smart cards do not allow to access data or functions addresses directly (for security reasons).

Based on this very simple model, we can see several functions that a smart card framework could provide:

• Communication level: A transport layer to control the reader and to communicate with the card (level 1), (following standard ISO protocols),

• Language level: A default infrastructure/system layer for interacting with the card OS data services (level 2), (being a filesystem-based card OS, a table-based database card OS, or an Object-Oriented card OS),

• Language level: Some more basic common system services such as naming, transactions, secure chanels, etc. (level 2? and/or 3?),

• Object Level: Some high level abstract interfaces or default components that are generic (i.e., horizontal services, see previous section) such are cryptographic services (level 3),

• Object Level: Some high level interfaces or components that are domain-specific (i.e., vertical services, see previous section) (level 3), such as payment, health, telecommunication etc. services.

As a consequence, the framework needs to define clear interworking interfaces for its components:

• Interfaces between applications components (Objects) and system components (OS). Standardized APIs (Application Programming Interfaces) will make application components independent from system components, e.g., a cryptographic card could be based on a FileSystem infrastructure or on a persistent object store,

• Interfaces between system components themselves: Standardizations of SPIs (System Programming Interfaces) would make them independant from each other (thus composable), and from communication components,

• Protocol interfaces between system components and communication components, for networking. A standard transport interface allows any system component to access smart cards through any card reader (at the condition, of course, that the right communication level component exists for the specific reader that is used!).

1.4 Requirements for the Framework

We now list here some generic requirements that we would like to be fullfilled by a standard smart card framework. Most are inspired by the Taligent whitepapers on Frameworks [1] and [2].

1.4.1 Simplicity

One can always choose not to use any framework to develop a card-aware application: to study ISO standards (protocols and standard commands), reader manufacturer documentation (control commands), and smart card manufacturer documentation (proprietary commands), and then to write a (big) piece of C code to do whatever is needed. Then, the first requirement for a good framework is not that it does exactly what is needed (it could be extended) or that it covers everything, but instead its simplicity. It must be:

• Small,

• Intuitive,

• Easy to use, and nevertheless

• Significantly high-level

In order to achieve the second point, we could add that its code should be readable enough for at least appropriate people to be able to understant it! (and this crowd could rapidly grow in the future...). Also, it should include well defined extension APIs (see below), and be well documented from a programmer's point of view (i.e., Javadocs-generated HTML is not enough!). We should also provide requirements, global design principles, explanations or pointers to patterns/coding choices, etc.

1.4.2 Extensibility

As we have seen in the framework definition (see paragraph 1.3.1), a good framework is a set of classes that is usable, but more importantly that can be adapted! It should be possible to:

Control

it through simple well defined mechanisms (this makes the difference between library classes and framework components),

Extend

it easily with new providers drivers that will be sub-classes of defined interfaces or abstract classes,

Extend

it with new types of services that were not taken into account at the framework design stage (e.g., adding support for non-standard cards or secured communications, or multiple sessions, etc.),

Compose

currently existing services in the framework in a random way, in order to address specific needs.

1.4.3 Applicability

Even if the framework intuitiveness is more important, in my opinion, than the functions it provides, as soon as it can be extended, it should nonetheless save some time by providing already implemented features and layers of abstraction! It should at least be based on the current card standards of the first type (see section 1.2), i.e., be applicable to:

• Current ISO protocol standards (7816-3 T=0 and T=1)

• Current ISO-compliant card OSes (7816-4, or 7816-7)

• Open Platform card OSes (Java Card[Tm] 2.1, MULTOS, WfSC)

• Current ISO application selection standards (7816-5)

1.4.4 Consistency

This is a corollary requirement from the first one (simplicity). In order to get users to gradually climb the framework learning curve and to efficiently capitalize when using it, the framework should provide consistent conventions and guidelines and enforce them with:

• Naming patterns (e.g., JavaBeans set/get methods)

• Design patterns (e.g., see use of the Factory Pattern in OCF, [15])

• Coding patterns (e.g., constant initializations, use of listeners and events, etc.)

For more on design patterns, see the ``Gang of Four'' bible book: ``Design Patterns - Elements of Reusable Object-Oriented software.'' [5].

1.4.5 Code Reuse

Whenever possible, the framework should provide some reference classes, default implementations for the most standard cases, etc.

Also, in order to allow for code reuse, we need a notion of modularity, i.e., a module should be able to use the services of a generic one. This is not so simple in the smart card world as it implies a precise management of critical sections (see below for more details).

1.4.6 Portability

Even if it is not a fundamental requirement from the user's point of view (his/her smartcard-aware application might never be ported to another platform), it is an important one for the framework implementors because they do not have to spend too much time porting it, and so they can focus on more useful work.

Thus, it is also important for users because wherever they run their applications, they can benefit from the framework, i.e., from the base classes and also from contributions or extensions that have been made available! (in a similar way, we could also state that the environment should be ``Free Software'', or at least ``Open Source'', which enforces its use and user-contributions). To take an example, if a very nice development GUI is made available under Windows, people using different platforms cannot benefit from it because it uses a non-portable toolkit (the same example can be taken with the Unix Motif toolkit!), as if this tool were developped in Tk or Java/Swing, it would have been automatically portable and so useful for more people.

For this reason we believe that general requirements for the framework should include:

• Platform-independance (hence the choice of Java: the framework will run on any machine running Java),

  Note that we also want the framework to be portable and eventually adapted to small devices, because the terminals running card-aware applications will not be limited to POS or GSMs like today, there will be applications running on Windows, on Linux or other Unixes, on Java-computers, on PDAs or even sometimes game-terminals !

• Language-neutral position: support for Visual Basic, C++, etc. should be provided, (e.g., through the use of multi-language ORBs, see next point),

• Interoperability with standard software bus: CORBA, DCOM. (Note: In Solaris 8, RPC mechanisms allow C or C++ applications to access OCF smart card services that are provided by the operating system).

1.4.7 Efficiency

The design of the framework should be done in such a way to maximize speed and minimize resources comsumptions. More specifically, we should try to minimize the framework core and components sizes.

1.4.8 Standardized

Although we have already emphasized the importance of standards, it is interesting to note that such a framework can have two major goals: 1) being useful for card-aware applications developers (hence the requirements above) and 2) being promoting a smart card open market (hence this last requirement).

The goal of an open market is to allow systems to include elements from different suppliers. Several suppliers may have offerings for the same card reader, or the same type of smart card. For instance, a Gemplus GPK card could compete with a card offering equivalent functionalities. Even if open markets do not seem to be good for suppliers at the beginning, they appear to dramatically widen the market size!

1.5 OpenCard to the Rescue...

The answer to these requirements for the members of the OpenCard consortium is OCF, the OpenCard Framework: it is an open standard providing an architecture and a set of APIs that enable application developers and service providers to build and deploy smartcard-aware solutions.

OCF APIs are pure Java classes and interfaces. They are also quite complete, as not only a communication layer exists, but also the other needed functionalities as described in paragraph 1.3.2: OS layer, Services, etc.

Besides the main motivations previously described, the choice of a state-of-the art framework technology would allow more requirements to be fullfiled.

We would like the framework:

• to provide interoperability between card readers (by use of a common API),

• and between cards with similar functionalities (by use of standardized interfaces). This way applications using cards can be portable and not bound to a particular vendor, like before.

• to provide reusability, by forcing the developers in good habits of writing generic components (and even by sharing them via Open Source with the rest of the community) instead of mixing card commands and application in a single code

• to offer high-level features such as

  1. Card recognition and automatic selection/creation of the right software component, and

  2. Management of concurrent accesses to a card or to a logical channel in-card.

Finally, as explained in details in the first part of this whitepaper, we have chosen to go for the framework technology, as we believe that the information technology world is going to be increasingly complex and dynamic, requiring more and more smart card security functions. We also believe that we will need some very open and flexible software middleware and tools to adapt to this situation (see [12] for more on this issue).

2.1 OpenCard Consortium

The OpenCard Consortium Purpose is to:

• Produce the OCF specifications,

• Extend them, Make them evolve (actually the job of the Technical Committee, see below),

• Foster the OCF acceptance, Ensure its distribution, Promotion,

• Assist in OCF use, Provide suites of tests for components compliance.

In 1997, a few companies started to work on a Java Framework dedicated to using smart cards: they were Bull, Gemplus, IBM, Schlumberger, SCM Microsystems, Sun, and Visa. IBM was the technical leader of the group. The first stable version of OCF (1.0) was demonstrated in spring 1998.

At the same time, those companies plus Dallas Semiconductor, First Access, Liberate Technologies (formely NC), and Ubiq formed the OpenCard Consortium in order to promote together OCF and accelerate its developments.

In 1998 3-G, Intellect, Newcom Technologies, and Siemens joined the group, followed by American Express in 1999.

2.2 Consortium Organization

The consortium is a non-profit US-based corporation with formal bylaws and organization.

The Consortium has:

• officers (treasurer, secretary),

• a management board : it is the main steering committee,

• and a Technical Committee, in charge of the evolutions of the framework.

2.3 OpenCard Technical Committee

The Technical Committee acts on behalf of the Management Board in order to manage the evolutions of OCF.

What is interesting is that at the beginning of 1999, we started to elaborate a formal Process of Work that was voted in March 1999 by the technical committee members and backed by the consortium Management Board.

This process has been inspired by other open processes of work of very well known organizations such as the IETF (Internet Engineering Task Force), the OMG (Object Management Group), or the W3C (World Wide Web consortium).

It is based on the submissions, discussions, and votes of RFPs and RFCs.

2.4 Process of Work

The OpenCard Consortium Technical Committee process is based on two major steps:

1. submission, review, and adoption of "Requests for Proposals" (RFPs),

2. submission, review, and adoption of "Requests For Comments" (RFCs).

For each of these steps, a review process is proposed in order to reach as quickly as possible a community consensus.

Intent of RFPs

The intent of a Request for Proposals (RFP) is to propose a new improvement for the OCF. It can be a change, an enhancement, an extension or an addition.

RFPs are concerned with a "what" description.

Example:
"It should be nice to have PKCS11 support in OCF, how could we do that?"

The rules for formatting an RFP are defined in RFC 2. The format of RFPs is actually described to be similar to the RFC format.

To summarize, an RFP is soliciting proposals from the different partners in the OpenCard Consortium TC on a particular issue related to OCF.

Intent of RFCs

The intent of a Request For Comments (RFC) is to propose a solution for a particular RFP.

RFCs are concerned with a "how" description.

Example:
"We should be using the com.ibm.pkcs11 Java interface, as proposed in Appendix A, and provide in addition a wrapper for native calls, what do you think?"

Each distinct version of an OCF standards-related specification is published as part of the "Request for Comments" (RFC) document series. This archival series is the official publication channel for OCF standards documents.

After an RFC has been approved by the technical committee and by the OCC management board, the proposed features or changes are integrated into the main tree of OCF versions. This is how version 1.1.1 and 1.2 have been developed, they include all the RFCs that have been voted as accepted respectively from January 99 to May 99 for version 1.1.1, and from May 99 to January 2000 for version 1.2.

Web Page

An overview of the process and the complete list of RFPs/RFCs that have been voted or are currently debated is available at the following URL:

http://www.opencard.org/work/

Already voted RFPs and RFCs are public while the ones that are still in their active period (20 days for RFPs and 40 days for RFCs) are restricted to the OCC members.

2.5 OpenCard Framework vs other Frameworks

In this section, we give a short overview of how the OpenCard architecture relates to PC/SC.

2.5.1 PC/SC, a PC-only Framework

PC/SC is the standard framework for enabling smart cards interoperability in the Windows95/98/NT world. It includes a C or C++ API. Any type of application language is usable through the DCOM software bus.

For an overview of the PC/SC architecture, see [20] and [21].

Recently, a group called M.U.S.C.L.E (i.e., Movement for the Use Of Smart Cards in a Linux Environment), lead by David Corcoran, University of Purdue, has developed from scratch a PC/SC resource manager for Linux (and other Unixes) that is compliant with the public PC/SC API specifications. For a presentation of this Linux port, see [22].

PC/SC is an important contribution to provide developers with a standard transport API and a transparent reader management through a ``provider'' architecture. However, we believe that OCF brings supplementary features to the application developers for two reasons:

• It is a non-Java solution: besides portability, the choice of Java for OCF is also reinforce by the fact that lots of modern technologies exist and are easily available in the Java world (e.g., ORBs, RMIs, Security Managers, Multi-threading (portable!), Naming Services, etc.).

  With this in mind, we can consider Java as a ``framework of frameworks'', the JDK APIs being offering to the programmers lots of standard ways of accessing databases, developing GUIs, dealing with files, etc.

  For more on this issue of interconnecting OCF with other Java frameworks such as Java.io, JDBC or JNDI, see section 3.4.

• It is a non-portable solution: we would like to be able to use a Framework to access smart cards on all possible systems, including but not limited to Windows systems and Unix workstations, but also Network Computers, PDAs, Mobile Equipments, etc.

2.5.2 Dedicated Frameworks

There are other frameworks that are currently in design/development stage. We can ask ourselves why: the issue is an adequation of the solution to the most important requirements.

For example, OCF's major goal, among those listed in this paper, has probably been the flexibility requirement, perhaps in its first versions at the expanse of simplicity and size, which was fine for an environment that is supposed to run on PCs, workstations, or NCs.

Now, for other type of platforms like small devices (payment terminals, payphones, set-top boxes, etc.) that want, at one time or another, to make a smart card transaction, the goals are different: we might accept less flexibility for the API in order to reduce its size.

For these platforms, it might be necessary to design a different framework that will fulfill different needs! Or, if the works that are currently undergone in the OpenCard Consortium Technical Committee succeed, we might have only one a-la-carte framework where not only we could leave aside some components that are not needed, but also some framework mechanisms if they are not needed!

An update of this works is the newly release of TOCF (Tiny OCF) a version specially designed for embedded devices. See [17].

As stated in the introduction, many documents are already available covering the technical details of OCF. We will here describe its general architecture, the major classes of its two layers, and how a smooth integration with other Java services (through Java frameworks or APIs) can be achieved.

3.1 Architecture

In OCF, there is a clear separation between mandatory packages that are part of the core of the framework (such as opencard.core.terminal, .events, .service, and .util), and packages that are optional: they then lie in the optional part starting with opencard.opt.

In this optional part, other packages related to terminal, services, security APIs, management etc. reside.

The OCF architecture is based on a layer model. The most upper layer is the ``Smartcard-aware Application'', it uses some components named CardServices that know about the Card application and/or OS and/or application management possibilities (selection, installation, etc.). These components in turns use some other components named CardTerminals that allow to communicate with the card through a reader.

If you remember that we would like the different parts of a smartcard-aware applications to be independent from each other, then the two major layers of abstraction of OCF are geared toward this purpose, i.e.,

• the CardTerminal layer encapsulates the different ways to use a reader (their OS, set of commands, and communication protocols can be different). Data classes provide models for well-known types of data such as APDUs or ATRs. Also other classes model components from the card reader (I/O channels, ..)

• then, the CardService layer encapsulates the different ways to use a card that provides a particular functionality, transparently of its Operating System, or of its application/applet implementation. The framework provides standard ways to use the card, for example to work with files, or to do cryptographic work.

• note that, included in the CardService layer, a special type of CardServices, Applet Managers, is able to load a new applet on a card, list available applets, select one for use, etc. The CardServices of that type are will be used by the card issuer to manage the co-existence of various applications on the same card (new feature of version 1.2).

Figure 2 summarizes this architecture.

  

Figure 2: OCF Architecture

So the two main Java packages of the OpenCard Framework are (we will describe into more details these two packages in the next sections):

1. the CardTerminal package, which manages access to a card terminal, and

2. the CardService package, which provides the necessary infrastructure to interact with a card Operating System and/or a card application.

Some Highlights of this architecture are:

• We have a complete Framework: some high-level services are provided,

• A Factory/Registry scheme is used in both levels: it is a design pattern that allows to avoid hard-coding objects creations (see [5]),

• the concurrent access to the resource (i.e., the smart card, or logical channels), is managed by the framework itself,

• We have some clear interworking interfaces at all levels, not only at application levels (APIs), allowing not only to write portable applications, but also to completely decouple ``providers components'' (e.g., a CardTerminal driver do not know for which CardService it will work, and the reverse is also true, an application do not see the CardTerminal layer unless it wants to access special features such as reader screen and keyboard management, etc.),

• OS or applet service selection based on ATR standardization and analysis (i.e., temporary communication with the card or applet) since version 1.1.1.

3.2 Details on the CardTerminal layer

In this section, we study the CardTerminal layer of OCF.

The CardTerminal layer encapsulates all classes that allow access to a smart card terminal or reader.

The main classes of the card terminal layer are in the packages:

opencard.core.terminal (mandatory classes and interfaces) and opencard.opt.terminal (optional classes and interfaces)

These classes are:

CardTerminal

abstract class from which concrete implementations of specific terminal drivers derive (e.g., GemplusCardTerminal, IngenicoCardTerminal)

The abstract "internalSendAPDU" method must be implemented by the concrete terminal driver.

Each CardTerminal has one or more card slots, and can optionally have a display and/or a pin-pad.

CardID

it is the class modeling the information contained in the ATR sent back by the card. It is interesting to note that this class is the "heart" of OCF as this information will be latter analyzed in order to select CardServices and applications. If this information is not sufficient, the CardServiceFactory is allowed to communicate with the card in order to decide if it can create a CardService that can handle it or not (new feature of version 1.1.1).

CommandAPDU, ResponseAPDU

these classes are modeling APDUs transport packets.

3.3 Details on the CardService layer

In this section, we study the CardService layer of OCF.

The CardService layer provide APIs that will be used either by smartcard-aware applications, or by other CardServices (we have here a notion of modularity that is barely found in other smart card access middleware).

This second layer (CardService) is probably the most interesting one for the application developers as they can consider it as a "toolbox" for developing their application:

• either they can use standard OCF interfaces in order to develop interoperable applications and re-develop from sratch a compliant CardService (i.e., use OCF as a repository of standard IDLs -see [7]-), in this case, they will be working at the TPDU/APDU level (communication and language level, see section 1.3.2),

• or they can use OS-level CardServices, such as those that can manage Java Card[Tm] applet selection or downloading, or those that can use ISO-normalized file or database systems on cards, etc. It is the intent of the framework to grow in order to offer such tools that can provide higher-level views of the card, see below for details on such services,

• or, at last, if somebody is providing a "business level" CardService adapted to a particular card (e.g., a Purse, or a PKCS11 compliant CardService, etc.), then they can just use the high-level APIs without knowing how the communication with a smart card is programmed they can even use such components by graphically connecting them to their application if they are packaged as Java Beans or EJBs.

  Note that such high level use of OCF in an application can be of two types:

  1. it can make use of a standard smart card API (e.g., PKCS11 or CDSA),

  2. or of an other framework (e.g., JDBC, JNDI) in which case, the connection between the two frameworks being provided, the application do not even have to worry about OCF except of the availibility of all pieces of the puzzle! In this latter case, Java can be considered as a good "framework of frameworks"!

The main classes of the card service layer are in the packages:

opencard.core.service (mandatory classes and interfaces) and opencard.opt.service (optional classes and interfaces)

These classes are:

CardService

abstract class from which concrete implementations of specific card drivers derive (e.g., GPK8000CardService, GemDBCardService, etc.)

SmartCard

The SmartCard object is the point of access to the OpenCard framework for the application. It allows the application to retrieve a specific service reference and use it, it also is tied to a CardServiceScheduler that models the smart card as a resource object (i.e., it manages access conflicts in case of multi-threaded application(s) or use of logical ISO card channels).

CardChannel

This class is the API for exchanging APDUs with the CardTerminal layer (and so through it and through the reader, with the card!). CardServices must do a P() and a V() on the resource to specify a critical section (i.e., in the OpenCard vocabulary they do an "allocateCardChannel" and a "releaseCardChannel") before and after using the CardChannel object to communicate with the card (using the "sendCommandAPDU" method).

In conclusion, although the CardService layer could be misunderstood as a simple layer providing translations of high-level API functions into APDU packets, it is much more than that: it provides a framework architecture also in the upper layers of OCF , which is then not restricted to card readers management! However, this CardService framework architecture has to be enhanced constantly with new APIs, new mechanisms, bridges to other frameworks etc. (see for example [18] and [19]).

3.4 Integration with other Frameworks

As explained above, when OCF is connected through some ``software bridge'' to an already existing Java framework, the application developer or user doesn't even have to know about OCF, except for specifying somewhere that a card will be used (!).

Some examples of this include:

• IO package. The java.io package of the Java API allows reading and writing using streams on all type of devices (e.g., files, streams). An equivalent package in OCF, opencard.opt.iso.fs, allows reading and writing on standardized ISO7816-4 smart card files. Classes from this packages inherit from their Java counterpart. As a consequence, a Java developer using the OCF package is able to see smart card files like regular Java streams, without a deep knowledge of the ISO norm or communication protocols.

• Connection to JDBC, the standard Java API for accessing databases: the application will use a database card such as the GemDB exactly the same way it can use an Oracle database (although, it will probably not do the same thing with it!). See [18].

• Using RMI techniques, a Java programmer can access JavaCard objects through proxies that implement the same interface. Thanks to this technology, CardServices are automatically generated from the description of the service interface. See [8] for more details. A standard way of accessing card objects through RMI is currently in the process of being specified by the JavaCard Forum.

• Connection to JNDI, the standard Java Naming and Directory Service API. Alain Macaire has developed a Java Card[Tm] applet that act as a mini-LPDA naming and directory server on a card. It has also provided a software component that plugs into the JNDI architecture and uses OCF (it is acyually a CardService). This way, applications use this small naming and directory server just as they would use other ones supported by JNDI such as DNS, NIS, LDAP, CORBA COS, etc. See [19].

In the future, we intend to experiment with the connections between the OCF framework and non-Java framework. Some experiments involving the newly distributed Linux PC/SC [22] that is entirely based on CORBA offers some interesting perspectives.

We have tried to give a rapid overview of all middleware requirements, techniques, and initiatives that exist arround the smartcard-access function. As we have seen, we are just at the beginning of a new area where software bricks and flexible architectures will allow application developers to develop much more efficiently. We believe that OCF is a good start for such Java Framework, and that everybody (the smart card industry, but also application developers interested in using smart cards), has to contribute in order to enhance this base.

Many references are given, both in the introduction section, below for web sites, and in the bibliography section, in order to allow the reader to read further and adopt the framework technology. We know, however, that the learning curve for such complex systems is not completely flat!, but the investment is certainly worth.

Taligent

A very good source of information for understanding the technology of Object-Oriented Frameworks is the set of Taligent white papers that have been published on their web site and are now hosted at IBM web site.

http://www.ibm.com/java/education/oobuilding/

Sun

General information, APIs, and Reference implementations for the Java Language can be found at the Java Technology Home Page: (Note: be sure to download the Java Communication API in order to be able to use pure java CardTerminal drivers; see PRODUCTS & APIS).

http://java.sun.com/

Opencard

The distributed version of OCF 1.2 is available from the OpenCard Consortium official web site. (For downloading the complete package see DOWNLOAD).

http://www.opencard.org/

Gemplus

Gemplus components, both for the CardTerminal and the CardService layers are available from the Gemplus Developers' web site.

http://www.gemplus.com/techno/opencard/

Frameworks, Design Patterns, Distributed Applications Models

1 ``Building Object-Oriented Frameworks.''

(http://www.ibm.com/java/education/oobuilding/)
by Adolfo M. Nemirovsky (Taligent).
Taligent White Papers.

2 ``Leveraging Object-Oriented Frameworks.''

Taligent White Papers.

3 ``Patterns and Protocols.''

(http://www.sigs.com/publications/docs/road/9605/road9605.c.booch.html)
by Grady Booch.
``SIGS Publications'', 1995.

4 ``A Forum for Fitting the Task.''

by Carl Nelson.
IEEE Computer, vol. 27, num. 3, pp. , March 1994.

5 ``Design Patterns - Elements of Reusable Object-Oriented software.''

by Gamma,Eric.,et al.
ISBN: 0-201-63361-2, Reading MA, Addison-Wesley, 1994.

6 ``Reference Model of Open Distributed Processing (RM-ODP): Introduction.''

(http://www.dstc.edu.au/AU/research_news/odp/ref_model/papers/icodp95.ps.gz)
by Kerry Raymond, DSTC, University of Queensland.

7 ``CORBA: A Platform for Distributed Object Computing.''

(http://www.infosys.tuwien.ac.at/Research/Corba/archive/intro/OSR.ps.gz)
by by Zhonghua Yang, Keith Duddy, DSTC, University of Queensland.

8 ``Developing Smart Card-Based Application using Java Card''

http://www.gemplus.com/smart/rd/publications/
by Jean-Jacques Vandewalle, Éric Vétillard, Gemplus Research Lab. France.
CARDIS'98, Louvain-la-Neuve, Belgium, Sept. 1998.

Smart Cards

9 ``Smart Card Overview.''

(http://java.sun.com/products/javacard/smartcards.html)
by Sun.

10 ``ISO/IEC 7816. ISO standard for ICCs with contacts.''

by ISO.

11 ``PKCS #11: Cryptographic Token Interface Standard.''

(http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-11.html)
by RSA.

12 ``New Architecture for Point of Transactions accepting Smart Cards''

by Thierry Collin, Dassault France.
Gemplus Developer's Conference 99, June 21st, 22nd, Paris.

OpenCard Framework

13 ``OpenCard Framework - General Information Web Document''

(http://www.opencard.org/docs/gim/ocfgim.html)
by The OpenCard Consortium.

14 ``OpenCard Framework 1.2 Programmer's Guide''

(http://www.opencard.org/docs/pguide/PGuide.html)
by The OpenCard Consortium.

15 ``OpenCard Framework''

(http://www.ibm.com/java/education/opencard-framework/)
by Reto Hermann, Dirk Husemann (IBM Research Division).

16 ``The OpenCard Framework and PC/SC''

by Matthias Kaiserswerth, IBM.

17 ``RFC15: OCF for Embedded Devices''

(http://www.opencard.org/work/rfc-15/rfc-15.txt)
by Thomas Schaeck, Peter Bendel, IBM.
See also implementation at:
http://www.alphaworks.ibm.com/aw.nsf/techmain/ocf4embedded

18 ``An OCF API for Database Smart Cards - JDBC Connectivity''

by Cedric Dangremont, Arnaud Hamel, Mastère en Base de Données et intégration de Systèmes, CERAM.
Gemplus Developer's Conference 99, June 21st, 22nd, Paris.
See also resulting RFC at:
http://www.opencard.org/work/rfc-20/rfc-20.txt

19 ``A Personal Naming and Directory Service for Mobile Internet Users''

(http://www.gemplus.com/smart/rd/publications/)
by Alain Macaire, David Carlier, Gemplus Research Lab. France.
USENIX Workshop on Smartcard Technology, Chicago May 11, 1999.

PC/SC

20 ``PC/SC Workgroup Overview''

(http://www.smartcardsys.com/overview.html)
by The PC/SC Workgroup.

21 ``PC/SC: v 1.0 and beyond''

by Bernard Gagnon, Gemplus R&D Canada.
Gemplus Developer's Conference 99, June 21st, 22nd, Paris.

22 ``M.U.S.C.L.E: porting the PC/SC architecture to Linux.''

by David Corcoran, MUSCLE Linux Security, Indianapolis, Indianna.
Gemplus Developer's Conference 99, June 21st, 22nd, Paris.

About this document ...

This document was generated using the LaTeX2HTML translator Version 99.1 release (March 30, 1999)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -ascii_mode -style ./ocf.css opencard.tex

The translation was initiated by on 2000-03-07