|
GCF

DoréDevelopment's many years of smart card knowledge have been used to develop the Generic Card Framework (GCF) in order to facilitate the porting of smart card applications for different platforms with different numbers of card slots, protocols and card types, with a maximum of reuse between different types of cards.
The development of GCF is a great success, so that the GCF and a number of protocols have been ported and used on a variety of platforms with a range of processors, smart card interfaces and operating systems.
The GCF is design-wise divided into two logical parts:
- The core functionality - which allows general handling of unknown generic cards and protocols on unknown platforms. This is included in all versions of GCF and does not change when integrating new cards and/or protocols.
- Card and Protocol - handles well-defined cards and communication protocols. This part is changed at integration of new cards and/or protocols.
The split between an interchangeable part and a static part is very important, since some cards and protocol types are only used under type approval and therefore must not be changed when adding more types of cards for a solution.
During the development of GCF core DoréDevelopment have chosen a more generic approach then letting the ISO 7816-3 and EMV specific types of cards to be dominant in the design. The kernel is designed according to the following criteria:
- All cards can be inserted or removed from a slot. (Fixed cards, as PSAM or SIM cards, are "only" is inserted.)
- All types of cards can be reset and give some form of ATR. (Otherwise, the card-type software generates one.)
- All slots can support a variety of card types.
- Only one activated card type in a slot is able to receive ATR's from a given card, eg. if both ISO 7816-3 and EMV cards will be activated only one of them receive and verify ATR.
- All communication is done in generic sessions, which must be permitted by the active type of card.
- All protocol type has a state machine and will be updated periodically.
- All card activities are trigged.
- No type-specific bindings are allowed in the interface between the core and interchangeable cards and protocols.
These criteria was used as minimum requirements to ensure a generic GCF core.
The core of GCF is divided into three parts, which gives a simple logical structure:
- Protocol Framework (MPF) - which gives an overall state machine, covering all the cards in a given slot. The state machine handles insertion and removal of cards, power and reset sequences.
- Application Programming Interface (API) - offers a simple well-defined interface for GCF.
- Hardware Abstraction Layer (HAL) - the integration of the specific hardware to be used by the GCF.
The replaceable part of the GCF functionality is divided into two subgroups:
- Cards - that binds a series of protocols together to support a given card specification. Cards handle communications to and from the API to make the protocols regardless of the type of card they are used under.
- Protocols - which handle communications interfaces from cards/GCF for a given card through a Hardware Abstraction Layer (HAL).
A full specification of GCF can be obtained from DoréDevelopment ApS.
|