Base OCF Reference Implementation  Changes for OCF version 1.1 Changes for OCF version 1.1.1
  Configuration  OpenCard Home


OCF Banner

Please read the  License!

News and Changes in OCF 1.2

 

Changes

This section gives an overview of the changes OCF has undergone from version 1.1.1 to 1.2. The changes that have been implemented are mostly changes which result from Requests for Comments (RFC) elaborated by the members of the OpenCard Consortium.

Changes Visible for Application Developers

OCF Installer
Application Management
Internal and External Authentication
Card Holder Verification
OCF for Embeded Devices
OCF Support for Java Cards
API Streamlining
Bug Fixes

Changes Visible for CardService Developers
Bug Fixes

Changes Visible for CardTerminal Developers

Terminal Locking
Bug Fixes


Change Details


OCF Installer

OCF 1.2 provides an easy to use OCF Installer package that provides developers with a quick way to get started with OpenCard development. This package consists of a single Java class file that contains all OCF components that were previously provided in the Convenience.zip file plus the full OpenCard API documentation and the OCF Programer's Guide. A graphical installation process guides the user through the configuration of the OpenCard Framework according to the installed hard- and software. On Microsoft Windows 9x/NT an OpenCard folder is added to the startup menu that contains links to available documentation and a few demo programs. To  use the OpenCard Framework a working installation of CardTerminal classes provided by the card reader manufacturer and Sun's Java Communications API need to be installed. The OCF Installer package has been tested on Microsoft Windows 95/98/NT. To run it you need JDK version 1.1 or higher.


Application Management

The Application and Card Management Card Service has been entirely changed and enhanced for OCF 1.2.

The base classes for describing and managing applets are moved from the pacakage opencard.opt.management to the package opencard.opt.applet.

The term "applet" as we use it in this documentation can be either a program, which is executed on the card itself (like a typical Java Card applet). Or it can be an application specific set of files and directory structures (as we will find on ISO compliant file system oriented cards). In both cases an AppletID is used to identify the applet in a world-wide unique way. There are standards which define how each smart card should hold a directory of AppletIDs, allowing any card-external application to decide, if it supports a particular card or not. Card-resident applets are described by meta-information encapsulated in AppletInfo objects.
This meta-information includes

You can obtain the AppletInfos from your SmartCard object using the AppletAccessCardService's list method. AppletID is a subclass of ID and has been formely named as ApplicationID. In OCF 1.1.1, the AppletInfo has been named as ApplicationTemplateclass. The ID class can be used as superclass for any other kind of identification (such as a GUID).

In the package opencard.opt.applet a very primitive CardService named BasicAppletCardService is introduced, which is only able to select a specific applet on a card.

The two Application and Card Management Card Service known from OCF 1.1.1 are renamed in OCF 1.2 as AppletAccessCardService and AppletManagerCardService. Both are defined in the package opencard.opt.applet.mgmt. Their functionality has been changed slightly:
The AppletAccessCardService includes the methods

The AppletManagerCardService provides the methods Implementations of these Card Services will be added to OCF as soon as they will get available. They will be placed in specific domain sub-packages like opencard.opt.javacard.mgmt or opencard.opt.emv.mgmt instead of being placed in the same opencard.opt.mgmt package.

It is intended that the AppletInfo class can be extended and that new features/types of information can be added for specific domains (e.g. JavaCardAppletInfo, placed in the package opencard.opt.javacard.mgmt).

A new abstract class named AppletCode is introduced. This class models the actual code of a card applet to be installed in the card. It can be constructed either by specifying a file name that is supposed to contain the code, or giving all bytes of the code in parameter. This class is the generic type that is passed as parameter to an install method. As in the previous case, it is intended that subclasses can be defined, with new features and/or different ways of reading a file to get the actual applet code.


Internal and External Authentication

In OCF version 1.1, the general assumption about access conditions that  have to be satisfied is that an application should not have to worry about. The implementation of the FileAccessCardService for IBM's MFC smartcards, for example, deals with external authentication transparently, provided that the application passed appropriate credentials to the service before using it.

One drawback of this approach is that an application has no control about the access conditions that are satisfied. Internal authentication is not supported at all, since it is not an access condition enforced by the smartcard. The credentials that have been provided to a service are used at the service's discretion, and the application has little or no control of what the service does with them.

There may be applications that require more control of the security features as is provided in OCF 1.1.1. These applications should be given a way to perform external and internal authentication explicitly. Also, applications should be able to undo an achieved external authentication. By defining a card service for this purpose, applications can take control of the security features using this service. Applications that do not need this control may still rely on the transparent mechanism.


Card Holder Verification

In OCF version 1.1, the general assumption about access conditions that have to be satisfied is that an application should not have to worry about. The implementation of the FileAccessCardService for IBM's MFC smartcards, for example, deals with Card Holder Verification without any involvement of the applications using it.
One drawback of this approach is that an application has no control about which Card Holder Verifications are performed at what time. For example, it is generally not possible to check whether the user has already been prompted for a password. Also, it is not possible to simply enforce card holder verification at application startup, or to reset the card holder verification when the application is done with the card. There may be applications that require more control of the Card Holder Verification as is currently provided. These applications should be given a way to perform card holder verification explicitly. Also, applications should be able to undo a successful card holder verification.
By defining a card service for this purpose, applications can take control of the card holder verification. Applications that do not need this control may still rely on the transparent mechanism, as long as the CardService to be used supports it.
The transparent mechanism for Card Holder Verification may still be useful. However, it's use is severly restricted by the definition of the interface opencard.core.service.CHVDialog, which returns a String holding the password or PIN. The card channel that evaluates this String can only apply a default conversion and paste the resulting byte array into a prepared command APDU. This is appropriate only for alphanumeric passwords in the locale of the Java environment in which the OpenCard Framework is running. It also assumes that the password has to be presented in plain format, not with secure messaging.
Performing Card Holder Verification is a complex task with multiple dependencies. Requesting the password from the card holder depends on the hardware that is available. For example, a screen dialog may be popped up, or an attached card reader's display and pinpad can be used. The command or commands to verify the password depend on the card OS. Length, encoding, padding, and the range of valid characters depend on the application and on the card layout. When specifying a CardService for Card Holder Verification, it has to be decided which of these dependencies shall be handled by the CardService, and which will have to be dealt with by the applications. There is no one, perfect solution to this problem.

Specifying a CardService at this level of abstraction does not rule outthe specification of other CardServices, performing the same task at a higher level of abstraction. There may still be CardServices for Card Holder Verification that do convert a string presented by an application to an encoding appropriate for the card.

A CardService for Card Holder Verification obviously needs a method that performs Card Holder Verification with the smartcard. Typical file system based SmartCards, like the German GeldKarte, support different passwords for subtrees of the file system, and also multiple passwords within the same subtree. On JavaCards, each applet may specify it's own set of passwords, too. Parameters to the verification method have to indicate the subtree or applet as well as the password within that subtree.
To specify the subtree on a file system card or the applet on a JavaCard, the tag interface opencard.opt.security.SecurityDomain can be used. It is implemented by class opencard.opt.iso.fs.CardFilePath, and may in the future be implemented by classes that identify security domains in other cards.
To specify the password within a security domain, a simple integer should be sufficient. The GeldKarte, already mentioned above as an example, supports passwords 0 and 1, IBM's MFC smartcards passwords 1 and 2, Gemplus' GPK cards passwords 0 to 7. Although all these are file system based cards, it seems likely that an integer allows to distinguish the passwords on other cards, too.
The third argument to the password verification method is the password itself. It should be passed as a byte array, giving the application full control of the encoding of the password. To use a protected PIN path, in which the application does not get to know the password at all, null can be passed instead. In this case, it is the service's responsibility to query the password, to encode it, and to prepare an appropriate APDU to send to the smartcard. If the terminal supports it, this responsibility may be delegated to it. Using a protected PIN path prevents the application from specifying an encoding for the password, but that problem is inherent in the concept of a protected PIN path. If the password has to be presented to the card using secure messaging, it is the service's responsibility to perform the required cryptographic operations. The return value for performing Card Holder Verification is a boolean that indicates whether the password was correct or not. Since the return value is generated by the CardService, it can only be trusted if the CardService is trusted.
Passing the password as a byte array leaves the question of the length of the byte array. File system based, ISO 7816-4 compliant smartcards have a password length of 8 byte. However, considering JavaCard and the flexibility of applets, other password lengths may also occur. To allow the application to prepare a byte array of appropriate length, there should be a method to query the required length. For ISO cards, this method can simply be implemented to return a constant 8, causing minimal overhead.
Other properties of the password, for example the encoding and padding rules, can be rather complex and may depend on application data that is not accessible to the CardService.
If the application is able to perform Card Holder Verification explicitly, thereby satisfying access conditions for data on the card, it should also be able to reset those access conditions. On file system based smartcards, this can typically be done by a SELECT operation that leaves the directory on the smartcard. Even if this is not possible, a reset of the smartcard can clear access conditions. Either way, all access conditions for the respective subtree of the file system or, in general, the security domain, are invalidated at once. The method does therefore not require a password number as an argument, the security domain is sufficient.


Java Card/Multi Application Card support

OpenCard Framework 1.1 only defined interfaces and access methods for file system oriented cards. The only support for JavaCards in OCF1.1 was an interface named JavaCardCardService in the package opencard.opt.javacard. This interface only declared a method that sends a given APDU to a given applet.

OCF 1.2 offers classes that provide basic functions like sending a particular APDU to a particular applet on the card. Furthermore, they support the programmer of proxy classes for applets in applet state handling. The same classes may also be used for multi application cards that allow application selection by application identifier.Therefore, in this section we use the term "applet" in a generic sense, for referring to JavaCard applets as well as applications on multi application cards.

The following classes and interfaces are added to the package opencard.opt.applet:


Terminal Locking

OCF 1.1 provides no means for locking a terminal or individual slots. These features are added to OCF 1.2 without changing the basic design of OCF and without breaking any existing code. Entire CardTerminal objects as well as individual slots can be locked and unlocked. Consistent behavior of the card service layer is assured. The right to use a locked terminal is bound to the thread that has locked the terminal

The Terminal Locking mechanism is based on four requirements we see for a card terminal and slot locking mechanism:

We expect this interface to be implemented by CardTerminal implementations for use with PCs, NCs etc, where we have multi-application/multi-thread scenarios. The locking interface will probably not be implemented by CardTerminals implementations to be used on dedicated, single-application devices.


API Streamlining

The changes for the API Steamlining bring a number of minor changes to the OpenCard Framework which are meant to make the API simpler, and implementations smaller.
Method abstract with timeout w/o timeout
getCardID yes yes yes
internalReset yes yes no
internalSendAPDU yes yes no
reset no yes no
Of these methods, only getCardID and reset are publicly visible. To minimize the changes for existing card terminal implementations, the following changes are made: That way, the API to be implemented by new terminals is a subset of the API that currently has to be implemented. Existing card terminal implementations can still be used, provided they are able to deal with the default timeout values that are substituted for the actual arguments. By deprecating the timeout features of the public terminal API, application programmers are aware of the fact that timeouts are not supported. The deprecated methods will be removed in a future release of OCF.
 
  • Changes for Reduced Package Dependencies

  • In OCF1.1.1, the packages opencard.core.terminal and opencard.core.event are recursively dependent on each other. The classes in the terminal package deal with event handling, and therefore depend on the event package. On the other hand, the class CardTerminalEvent in the event package stores the event source, that is a reference to a card terminal, and therefore depends on the terminal package. As the name suggests, the package opencard.core.event should deal with events in OpenCard. To achieve this, a variety of changes are required. All changes are made in a way such that current implementations of card terminals can still be used with deprecated methods. The recursive dependency between the packages, however, will remain until the deprecated methods are removed in a future release of OCF.


    Bug Fixes


    OCF for Embedded Devices

    OCF for embedded devices defines a subset of OCF that is suitable for embedded devices with only one card reader, potentially with several slots. This subset is implementable on  Embedded Java Virtual Machines efficiently and with small footprint.

    OCF for embedded devices has the following properties:


    News and Changes in OCF 1.1.1

    This section gives an overview of the changes OCF has undergone from version 1.1 to 1.1.1 The changes that have been implemented are mostly bug fixes and streamlining of code, but include also some minor design changes which result from Requests for Comments (RFC) elaborated by the members of the OpenCard Consortium.
     
     

    Changes

    We assume that there are basically three kinds of developers that use OCF: Application developers, CardService developers, and CardTerminal developers. Below, there are three lists with the major changes that affect each kind of developer. The hyperlinks will lead you to the detailed descriptions of those changes in the next section. 

    Changes Visible for Application Developers

    Changes Visible for CardService Developers

    Changes Visible for CardTerminal Developers


    Change Details

    Native Browser support

    Deploying OCF in a web browser environment has so far been limited to Sun's java plug-in (also called Activator). OCF 1.1.1 introduces support for the native Java Virtual machines and security concepts of potentially any browser with specific support for Microsoft Explorer and Netscape Navigator. Please see the OCF Programming Guide for instructions how to code/package applets to run under these browsers.

    The changes introduced for native browser support do not change existing interfaces and are only relevant for developers who want to deploy OCF from an applet running under those browser's JVM.


    Changed CardServiceFactory interface

    Card service factories can now communicate with the card to determine whether they can instantiate the requested card service. In OCF 1.1 card service factories could only use the CardID (ATR) to determine the type of card. But often the ATR was insufficent to determine whether the card could be supported.
    New card service factories (subclasses of opencard.core.service.CardServiceFactory) should implement the getCardType() and getClasses() methods.
    Existing factories that implement the knows() and cardServiceClasses() methods must now be derived from opencard.opt.service.OCF11CardServiceFactory to compile without errors.

    Changed behaviour of SmartCard.waitForCard()

    SmartCard.waitForCard() does now block the caller until a card matching the card request is found or until the timeout expires.
    In OCF 1.1 waitForCard() returned whenever a new card was inserted, regardless whether the card inserted matched the card request. The method returned null when the card did not match the request.




     

    News and Changes in OCF 1.1

    This section gives an overview of the changes OCF has undergone from version 1.0 to 1.1. The changes that have been implemented are not restricted to bug fixes, but include a considerable number of design changes.
    The Rationale tells you why we decided to change the OpenCard API. In Changes, you will find lists of the changes that affect applications, CardServices, and CardTerminals written for OCF 1.0. Detailed descriptions of the major changes are presented in the Details section. 


    Rationale

    Changing a published API in a way that breaks code written against it causes trouble. It does not only require a considerable effort from our side to adapt the reference services and terminals. It also requires effort from your side to adapt your programs to the new API. However, we had good reasons for changing the OCF API. This section is meant to give you an overview on some of these reasons and motivate you to upgrade from OCF 1.0 to 1.1. (We promise not to do it again - unless the consortium members have overwhelming reasons.) The changes we implemented have been guided by the following objectives:

    Codesize Reduction

    Several functions of OCF have been reduced to save code size.  The changes were discussed and agreed by the Core Workgroup and the CardService Workgroup of the OpenCard consortium.  The policy was to save code that is rarely used and not essential while keeping incompatibility to version 1.0 at a minimum.  Version 1.1 of OCF allows to use the terminal layer without the Service layer, which is an option for small systems with memory limitations.  In this case the size of the terminal layer (with tracces removed and using the Jikes compiler) is 32 KBytes.

    We have simplified and split some of the CardService interfaces. This provides a chance for implementing smaller CardServices with support for the most frequently needed functionality of a smartcard. There is an improved layering between other parts of OCF, too. This allows for downsizing by using only the lower layers. Additionally, it simplifies the task of getting started with OCF. A developer can now start by looking at smaller parts of OCF and move to the more complex APIs later.

    Performance Tuning

    In general, we have modified internal functions and parts of the structure to allow for faster execution and reduced garbage collection overhead.

    In the CardService area we have introduced a layering for the opt.iso.fs package, where you can chose between highest abstraction and ease of programming or highest execution efficiency. For example, the time we measured for reading the 64 bytes card holder data in the Stockbroker demo was 0.65 seconds using OCF's java.io specializations, 0.52 seconds using CardFile and the file service directly, and 0.46 seconds using CardFilePath and the file service.

    We have reduced the tracing information generated.  The tracing output was always composed before the tracer decided if the tracelevels required to output it or not.  This involved overhead in some functions even if the trace was not used.  This overhead was reduced.  In addition, the traces can be removed from the code completely using a simple perl script.

    We have allowed the reuse of exising objects instead of create/delete cycles.  This puts a small additional burdon on the programmer writing a CardService implementation, but is transparent to application programmers. The performance could be improved significantly.  For example, by making CardChannel objects reusable, the time for reading data records has been reduced by 69% in one of our test programs, without breaking any code.

    We have replaced the OCFEventMulticaster by an implementation that is dramtically faster for a small number of events, like typical OCF setups have. Details

    Error Handling

    OCF exceptions were not checked in 1.0.  This made programming errors possible, where severe errors at runtime were not handled appropriately by the application code.  OCF 1.1 has moved to and enforces a stricter control of exception handling, which is more consistent with other Java frameworks.  Unfortunately, this change will break existing code that failed to handle OCF exceptions. Details

    Documentation Enhancements

    The API documentation has been greatly enhanced to provide more information. Especially the CardService interfaces for file access and signature generation have been documented in detail.

    The Programmer's Guide to OCF has been reworked to reflect all changes implemented in OCF 1.1. The code examples have been reviewed, simplified, and explained in more detail. 


    Changes

    We assume that there are basically three kinds of developers that use OCF: Application developers, CardService developers, and CardTerminal developers. Below, there are three lists with the major changes that affect each kind of developer. The hyperlinks will lead you to the detailed descriptions of those changes in the next section. 

    Changes Visible for Application Developers

    Changes Visible for CardService Developers

    Changes Visible for CardTerminal Developers


    Change Details

    Checked Exceptions

    The exception hierarchy defined in OCF 1.0 has been reviewed and changed. Some obsolete exceptions have been removed, others have been renamed. Finally, seven exceptions have been moved from opencard.core.service to opencard.opt.service.
    To help programmers in developing error handling code, OpenCardException and all exceptions derived from it are checked now. These exceptions must be caught or declared in the throws clause of method declarations. OpenCardException is a subclass of java.io.IOException, so applications that use the OCF specializations of the java.io package will require only few changes.

    CardID

    In OCF 1.0, the class opencard.core.terminal.CardID served a dual purpose. It represented a smartcard's ATR, and it could be used as a template for matching a set of ATRs. In order to do this, it included methods that tried to determine the card OS from the ATR. This functionality relied on a particular structure of the ATR, which was not fully specified. It also lead to a lot of confusion about OpenCard compliant ATRs and OpenCard compliant smartcards.

    In OCF 1.1, the CardID class simply represents a smartcard's ATR, optionally along with the terminal and slot in which the card has been inserted. Interpreting the ATR is the responsibility of the available CardServiceFactories. The notion of OpenCard compliance has been removed completely. There is no requirement that makes an ATR, or a smartcard, OpenCard compliant. If there is a CardServiceFactory that recognizes the ATR, OCF can deal with the smartcard.
    For selecting particular ATRs in a CardRequest, the interface CardIDFilter has been introduced. It can be implemented by an application in any appropriate fashion. The template functionality of CardID in OCF 1.0 did not provide this flexibility.

    Event Handling

    The event handling in opencard.core.terminal has been simplified. All terminal events are now broadcasted via the CardTerminalRegistry. Registering as listener at a CardTerminal is still supported, but deprecated.
    The registry events that notified applications about CardTerminals that have been dynamically added or removed are no longer available. Since an application gets the events of all CardTerminals via the CardTerminalRegistry, there is no need for them anymore.
    The event broadcast is done in a simple loop over a vector of listeners. The class OCFEventMulticaster has been removed. Registering or unregistering listeners at an event multicaster caused considerable overhead, which is now avoided.

    APDU classes

    The classes APDU, CommandAPDU, and ResponseAPDU have been changed to allow reuse of APDUs. For ResponseAPDU, the majority of the changes is transparent. On the other hand, CommandAPDU has changed considerably. Instead of the various constructors for different ISO cases, there are only constructors to initialize a buffer. The actual APDU is composed by invoking append methods that add bytes or byte arrays to the buffered APDU. Optionally, an APDU can be prepared in a byte array and passed to one of the constructors of CommandAPDU. This change will affect all existing CardServices. Here is an example of reusing an existing CommandAPDU object:

           apdu.setLength(0);

           apdu.append(cla);
           apdu.append(ins);
           apdu.append(p1);
           apdu.append(p2);

    The new class ISOCommandAPDU in opencard.opt.terminal provides the constructors formerly found in CommandAPDU, along with the extended diagnostic output in toString. It is meant as a help for debugging, but should not be used in production code.
    For consistency of method names, pduLength and pduBytes have been renamed to getLength and getBytes, respectively. This will require minor changes in existing CardTerminal implementations.

    CardService Instantiation

    In OCF 1.0, CardService instantiation used the java.lang.reflect package. The dependency on the reflections package is a major drawback, since OCF should support embedded devices with small memory resources, too. To overcome this problem, a CardService for OCF 1.1 has to provide a default constructor without arguments.
    If the constructor with three arguments, as required for OCF 1.0, did nothing but invoke the base class constructor, just define an empty public default constructor. If the constructor performed initializations that depend on those arguments, the method CardService.initialize has to be overwritten. In this case, don't forget to invoke the base class implementation of that method.

    For sake of method name consistency, chvDialog has been renamed to getCHVDialog. Also, the documentation of CardService and it's methods has been extended.

    IO classes

    The java.io specializations provided by OCF in the opencard.opt.iso.fs package have been reworked. The API offered some features that have never been implemented, or refer to non-ISO functionality that can not be expected of a file system based smartcard. Some of the changes are also related to the revised File Services. In particular, the following changes have been implemented:
    Class CardFileOpenMode has been removed.
    The class was an anachronism related to concepts that have been dropped for OCF 1.0. Whether card access is blocking or not is specified at the time a CardService is created. When creating an instance of CardFile, it is already fixed and cannot be overridden. Removing this class resulted in changes to the constructors of CardFile.

    Class CardFileInfo has been replaced by an interface.
    The class CardFileInfo imposed a fixed structure on the implementation of a file service. For example, it required the service to cache whether a PIN has been entered for accessing a file. And, obviously, the class used by a service to represent file info had to be derived of CardFileInfo.

    This situation has been relaxed by replacing the class by an interface. The interface defines some methods to query standard information, for example whether it is a directory or a data file. The amount of data that can be queried has been reduced to what is needed for file access. For example, there is no method to query access conditions since it is up to the file service to deal with them.
    Class CardFileType has been removed.
    The class CardFileType, which indicated whether a file is a directory or a data file with a particular structure, has been replaced by a set of query methods in CardFileInfo (see above). Instead of asking the file info for the file type and comparing the type to a predefined constant, the file info can be asked directly whether it is a directory, a cyclic file, and so on. This seems more natural in an object-oriented environment and reduces the code size of the framework.
    Class CardAccess has been removed.
    Class CardAccess was meant to represent access conditions to files on the smartcard. Unfortunately, not all kind of access conditions could be represented by that class or a specialization of it. For example, disjunctions of conditions, like "CHV or external authentication" could not be dealt with. Apart from that, the class was needed only at two places: the class CardFileInfo from which it has been removed (see above) and when creating files, which is not part of the ISO 7816-4 functionality (see below).

     

     
     
     
     
     
     
     
     
     

    Implementing a request of the CardService workgroup, the class CardAccess has therefore been removed. A file service implementation can represent access conditions as part of the file info in any way suitable for the particular smartcard. Applications should not have to deal with access conditions at all, since it is the responsibility of the card service to satisfy them.

    Class CardFile has been revised.
    The class CardFile in OCF 1.0 was modelled closely after the class java.io.File. This resulted in some methods that are hard or impossible to map to smartcards, like list or readable. These have been removed, along with some attributes that are not really needed, like fileSeparator.

    The references to the removed classes mentioned above had to be removed. This implied changing all constructors to remove the reference to CardFileOpenMode. The create method has been changed to the new FileSystemCardService interface (see below). mkdir has been removed completely, since it would have been identical to the new create.
    Some methods have been renamed for consistency. For example, path is now getPath, length is now length, and fileInfo became getFileInfo. Duplicate methods that accepted a string instead of a CardFilePath have been removed, to minimize the number of temporary objects that are created.
    For convenience, CardFile implements the CardFileInfo (see above). All methods are mapped to invocations of the file info object returned by the underlying file service. The advantage is that methods like isDirectory can be invoked directly on the CardFile object instead of getting the info first.
    The key handling has been revised and moved.
    The classes KeyStore and KeyBag defined a key handling mechanism required for satisfying access conditions that involve cryptography. This functionality is not specific to file system accesses, or even file system based smartcards. The key handling has therefore been revised and moved to the package opencard.opt.security. (Details)

    File Services

    The interface FileSystemCardService as defined in OCF 1.0 suffered from several drawbacks. First of all, it required support for functionality that is not defined in ISO 7816-4, like creating files. Second, it introduced dependencies on many of the classes defined in the opencard.opt.iso.fs package. Third, it defined key handling functionality that is not specific to the file system, but could also be required for signature generation or other operations supported by a smartcard. To overcome these drawbacks, several changes have been implemented.

    The key handling functionality has been moved from opencard.opt.iso.fs to opencard.opt.security (see below). The ISO functionality has been moved to a new, simpler interface named FileAccessCardService. The name has been chosen since ISO specifies only commands for accessing files and their contents, but not the creation, deletion or comparable operations typically found in a file system. The FileSystemCardService extends the file access interface by methods to do exactly that. It is up to the developers of file services whether one or both interfaces are implemented. Applications should use only the file access interface to be independent of a particular smartcard.
    To reduce the dependencies on other classes and interfaces in the iso.fs package, the signatures of the methods in both service interfaces have been changed. The dependencies are now restricted to the class CardFilePath and the interface CardFileInfo. Dependencies on CardFileOpenMode, CardFile, CardFileType, CardAccess, CardRecord (and maybe some more) have been removed. Unfortunately, this requires changes in existing implementations of the file system service. Applications will need some minor changes, too.

    Here are the highlights of the changes in the file service interfaces:

    Signature Services

    The interface SignatureCardService as defined in OCF 1.1 suffered from several drawbacks. First, it merged the functionality of generating and verifying signatures with that of importing keys to the smartcard. Second, the support was restricted to the RSA algorithm. DSA, or other algorithms that may become important in the future could not be integrated. Third, there was no interface for generating key pairs on the smartcard itself, which is supported by some cards. Fourth, using the smartcards for signatures may require satisfying access conditions similar to those for file access (see File Services above), but there was no way to pass authentication keys to the service. Last but not least, the SignatureCardService in OCF 1.0 used CardFilePath to refer to keys. The interface could therefore only be used for file system based smartcards, but not for JavaCards.

    To overcome these problems, the interface SignatureCardService has been split, the method signatures have been changed to support various public key algorithms, and a new interface for key generation on the card has been defined. All interfaces extend SecureService (see Key Handling below) so authentication keys can be provided. Of course, the documentation of the methods has been enhanced.
    Here are the three interfaces in opencard.opt.signature and a short description of the functionality they define:

    SignatureCardService
    Provides methods to sign and to verify signatures on data or hashs on data. References to the keys on the smartcard are generic and can be specialized to paths or cardlets. The algorithm for signature generation or verification can be specified by strings. The algorithm names are those defined by the Java Cryptography Architecture (JCA). Optionally, the padding algorithm can be specified in the same way.

    The OCF 1.0 methods to generate and verify signatures are still defined in the interface, but deprecated. These methods introduce a dependency on the opencard.opt.iso.fs package. They are likely to be removed in future versions of OCF, for example for embedded devices.
    KeyImportCardService
    This extension of the SignatureCardService defines methods to import private or public keys to a smartcard. Import can be done with plain keys, or with keys that have a signature attached to them which will be checked by the card. Generic references are used to specify the place to put the key.

    Generic key representations are used to pass the key data. A particular implementation of this CardService interface will convert the generic representation to a card specific one. In OCF 1.0, the key had to be passed in a card specific representation.
    KeyGenerationCardService
    This extension of the SignatureCardService defines a method to generate a key pair, that is a private key and matching public key, on the card. A second method is defined to read the generated public key from the card. The private key will never leave the card, which ensures a high level of privacy.

    Key Handling

    In OCF 1.0, the FileSystemCardService interface was the only one that defined support for secret keys. Such keys are used to satisfy access conditions that involve cryptography. The concept for key handling was that an application provides the keys, while the service contains the cryptographic code to satisfy the access conditions. For OCF 1.1, several changes regarding key handling have been implemented:


    This page was created by Frank Seliger, Roland Weber and Lothar Merk.