Project

General

Profile

Architecture » History » Version 2

Hans-Martin Haase, 08/20/2015 03:56 PM
Initial draft for a new architecture and design description.

1 1 Hans-Martin Haase
h1. Architecture
2
3
On this wiki page and subsequent wiki pages the design and architecture of the Open eCard App is described.
4
5 2 Hans-Martin Haase
h2. High Level Design
6
7
The Open eCard design is inspired by the eCard API Framework specified in BSI-TR03112 which itself relays on the standards CEN15480 and ISO/IEC24727. An overview of this high level design is provided in the following picture:
8
9
p=. !OpenECardHighLevelDesign.png(High level design of the Open eCard App)!
10
11
As the figure depicted the design is covered by multiple modules. This has the advantage that the components are more or less independent and exchangeable for instance the default IFD is implemented for a smart card stack called PC/SC but it might be simply replaced by an implementation for SICCT smart card terminal. Another example is the GUI module the richclient application uses a Swing implementation of the UI and in the Android client there it is replaced by an Android specific UI implementation. Following the main modules are explained.
12
13
h3. GUI (Graphical User Interface)
14
15
The GUI is connected via an abstract interface which allow to easily exchange the it. The abstract interface is required because an implementation is always specific for a platform for instance the Swing GUI of the Richclient is not usable on Android because the Java implementation of android does not provide the Swing framework. So an abstract description of the user interface was necessary, the abstract components are usable by all components requiring a interaction with the user. The platform dependent user interface implementation has to interpret the abstract components and visualize them.
16
17
h3. IFD (Interface Device)
18
19
The _IFD_ provides a message oriented interface according to ISO/IEC 24727-4 which is capable to access ISO/IEC 7816-4 based devices like smart cards. As you can see in the the design picture the _IFD_ contains sub modules which provide additional interfaces for the communication with the devices. The depicted _PACE_ module enables the application to use the PACE protocol which allows secure communication between the device and the terminal accessing the device.
20
21
h3. EventManger
22
23
The _EventManager_ is responsible to detect hardware relevant events and propagates them to the rest of the system. Examples for such events are the addition or removal of a card reader or a card. The _CardRecognition_ module of the _EventManager_ is used to identify inserted cards. The recognition module is also extensible so it is easily possible to support a new smart card or device by providing a so called CardInfo file which is an XML file containing a description of the card. The description maps the ISO/IEC 7816 operations to the functions provided by the eCard API Framework.
24
25
h3. SAL (Service Access Layer)
26
27
Similar to the _IFD_ is the _SAL_ a message oriented interface according to ISO/IEC 24727-3. The _SAL_ provides als an extension mechanism, which enables the addition of new authentication protocols without changing major parts of the implementation.
28
29
h3. Dispatcher
30
31
The dispatcher provides a centralized entry point for the handling of incoming and outgoing messages. This reduces the amount of Java code and the complexity of the Open eCard App.
32
33
h3. Add-ons
34
35
36
37
h3. Bindings
38
39
40
h3. Browser Integration
41
42
43
44
h3. Crypto
45
46
47
48
49
50
51
52 1 Hans-Martin Haase
Project structure: [[Project-Structure]]