GST Stuttgart LAb Test Site - Ertico

Global System for
Telematics
D4.3 Description of
Stuttgart lab prototypes
Author(s) Rainer Kroh, Jochen Hämmerle (DaimlerChrysler AG)
Date Contractual: 15/06/2006 Actual: 30/09/2006
TS Manager Jürgen Wojatschek
DaimlerChrysler AG
Tel: +49 7031 4389 523
E-Mail: juergen.wojatschek@daimlerchrysler.com
IP Manager Peter Van der Perre
ERTICO-ITS EUROPE
Tel: +32 2 400 07 36
E-Mail: p.vanderperre@mail.ertico.com
Abstract Stuttgart Lab Test Site description of testing environment and detailed
description of test activities.
Keyword list GST-Prototype development, Test Sites
Nature of deliverable
Deliverable
Number
Version 2.0
Dissemination PP
Report
DEL_TS_4_3_Stuttgart
Project financially supported by
Project number FP6-2002-IST-1-507033
European Union
DG INFSO

Version
number
Control Sheet
Version history
D4.3 Description of Stuttgart lab prototypes
Date Main author Summary of changes
0.1 2006/06/06 Rainer Kroh First draft
0.2 2006/06/14 Rainer Kroh Integration of Software and Hardware description
of Client and Control Centre (chapters 3.2.1, 3.2.2,
3.3.1, 3.3.2) and Executive Summary
0.3 2006/06/20 Jochen Hämmerle Integration of Class diagrams for Client and Server
implementation
1.0 2006/06/27 Rainer Kroh Incorporating CAG comments
2.0 2006/09/22 Jochen Hämmerle Integration of student project results
Approval
Name Date
Prepared Rainer Kroh 22.9.2006
Reviewed Rainer Kroh 22.9.2006
Authorized Rainer Kroh 22.9.2006
Circulation
Recipient Date of submission
Project partners 22.09.2006
European Commission 30.09.2006
30/09/2006 II Version 2.0

Table of Contents
D4.3 Description of Stuttgart lab prototypes
Chapter 1 - Introduction .............................................................................................5
1.1 Intended Audience.........................................................................................5
1.2 Organisation...................................................................................................5
1.3 Typographic Conventions..............................................................................5
1.4 Objectives ......................................................................................................5
Chapter 2 - Executive Summary Stuttgart Lab Test Site ........................................6
Chapter 3 - Lab Test Site Infrastructure..................................................................7
3.1 Lab Test Site Configuration Overview..........................................................7
3.2 Client System.................................................................................................8
3.2.1 Client Software and Hardware Configuration ...............................................8
3.2.2 GST Reference Implementations...................................................................8
3.2.3 Client System Lab Test Site Applications...................................................10
3.3 Control Centre .............................................................................................15
3.3.1 Control Centre Software and Hardware Configuration...............................15
3.3.2 GST Reference Implementations.................................................................16
3.3.3 Control Centre Lab Test Site Application ...................................................17
3.4 Testing/Monitoring and Remote Vehicle Diagnosis ...................................21
3.5 Live-CD .......................................................................................................24
Chapter 4 - Conclusions and Next Steps..................................................................27
References...................................................................................................................28
30/09/2006 3 Version 2.0

List of Figures
D4.3 Description of Stuttgart lab prototypes
Figure 1: Sub-project Components ..........................................................................................................6
Figure 2: General Overview of the Stuttgart Lab Test Site......................................................................6
Figure 3: Stuttgart Lab Test Platform......................................................................................................7
Figure 4: Photo of Stuttgart Lab Test Site................................................................................................8
Figure 5: Reference Implementations in the Client..................................................................................9
Figure 6: CRL Request considering as example for implemented components......................................10
Figure 7: Class diagram of CSMS client implementation......................................................................12
Figure 8: CSMS Vehicle Front-end Interface (e.g., CRL Update Failed / Root Cert Update OK) ........13
Figure 9: CSMS Vehicle Front-end Interface (e.g., Complete Update of Certificates and CRL) ..........14
Figure 10: CSMS Logging Interface ......................................................................................................15
Figure 11: Reference Implementations in the Control Centre ...............................................................16
Figure 12: Class diagram of Simple Open CA implementation .............................................................18
Figure 13: EJBCA - First part of a certificate profile............................................................................19
Figure 14: EJBCA - Second Part of a certificate profile........................................................................19
Figure 15: EJBCA - First part of an entity profile.................................................................................20
Figure 16: EJBCA - Second part of an entity profile .............................................................................20
Figure 17: Sequence diagram of Vehicle Diagnosis Application...........................................................21
Figure 18: Implemented VehicleAdminTree for the Vehicle Diagnosis Application..............................22
Figure 19: Vehicle GUI on the Client Side ............................................................................................23
Figure 20: Web-Interface of the Monitoring Center ..............................................................................24
Figure 21: Live-CD Certificate Management (Knopflerfish).................................................................25
Figure 22: Live-CD Certificate Management (CSMS-GUI) ..................................................................25
Figure 23: Live-CD Simple Open-CA ....................................................................................................26
30/09/2006 4 Version 2.0

Chapter 1 - INTRODUCTION
1.1 Intended Audience
D4.3 Description of Stuttgart lab prototypes
This document is primarily written for the members of all SP and members of WP4 Prototype
development as well as members of WP5 Field Trials and WP6 GST validation.
Some versions of the document will be circulated to IPWP3MT, CT and CAG for IPlevel
co-ordination purposes. The final version will be sent to GA.
1.2 Organisation
This document contains a description of the prototypes implemented at the Stuttgart Lab
Test Site.
1.3 Typographic Conventions
The following typographic conventions are used in this document:
Comments and Explanations Comments and explanations are written in a bold
Font. They are used in “empty” sections in order
to explain what kind of description is expected in
the section
A word starting with a capital letter Indicates a specific term explained by the appendix
Terms and abbreviations
Code Examples Code examples are printed in a courier font
C:\Project\MyCode.c Filenames are represented in a courier italic font.
Locales Words that have a specific meaning are printed
in an italic bold font
[1] Numbers in square brackets are references to
publications listed in the appendix.
1.4 Objectives
The objective of this document is to give an overview of the lab prototypes developed
and/or deployed at the Stuttgart Lab Test Site.
30/09/2006 5 Version 2.0

D4.3 Description of Stuttgart lab prototypes
Chapter 2 - EXECUTIVE SUMMARY STUTTGART LAB
TEST SITE
This document presents the interim results of Work Package 4 “Prototype development”
for the GST project as far as the test site is concerned.
WP1
Project management
To and from all WPs
WP2 WP3 WP4
WP5
WP6
Use cases &
system requirements
Figure 1: Sub-project Components
Architecture &
interface specifications
WP7
Dissemination and
exploitation
Prototype
development
To and from all WPs
Field trials
Validation
WP Manager
WP Participants
The deliverable DEL_TS_4_3_Stuttgart includes the implementation description of the
applications (test cases) in the Stuttgart Lab Test Site and shows some snapshots and the
use of various GST reference implementations.
Figure 2: General Overview of the Stuttgart Lab Test Site
30/09/2006 6 Version 2.0

D4.3 Description of Stuttgart lab prototypes
Chapter 3 - LAB TEST SITE INFRASTRUCTURE
3.1 Lab Test Site Configuration Overview
The Stuttgart Lab Test Site is using a lab test platform as shown below (see also [1]). It is
build up with 2 Desktop PCs which are connected via Ethernet. One PC is representing
the Client (Vehicle), the second PC the Control Centre. Because of the need for a Certification
Authority (CA), which is not part of the Control Centre (as specified in [4]) a
third PC could be used for handling the CA functionalities. In our current configuration
the Control Centre and the CA is running on the same PC.
Figure 3: Stuttgart Lab Test Platform
30/09/2006 7 Version 2.0

Figure 4: Photo of Stuttgart Lab Test Site
3.2 Client System
D4.3 Description of Stuttgart lab prototypes
3.2.1 Client Software and Hardware Configuration
The Stuttgart Lab Test Site uses the following software and hardware for the client system:
o IBM Laptop T43 Pentium M
o Operating System Debian Linux 2.6.x/Windows XP
o OSGi framework: Knopflerfish_osgi_2.0-beta
o Java virtual machine: Java 1.5.0_05-b05
o GST Reference Implementations: see chapter 3.2.2
o Services: These are the applications, deployed in the form of OSGI bundles,
see chapter 3.2.3
3.2.2 GST Reference Implementations
One evaluation goal of the Stuttgart Lab Test Site is the use of the GST Reference Implementations
as they are implemented to fulfil the realization of the various Test Cases.
In the current implementation the following RIs are used (see also [2]):
30/09/2006 8 Version 2.0

Test Site Stuttgart
GST / SP Interfaces used RI used
[Yes/No]
SP-TC used
[Yes / No]
D4.3 Description of Stuttgart lab prototypes
ETS used
[Yes / No]
Explanation
OS-CP Communication
Manager
Yes Yes Yes
SEC-CP Certificate Management
Yes Yes Yes
SEC-CP Security Module Yes Yes Yes Small modifications
of RI Security
Module to include
certificate management
SEC-CP Secure Communication
Engine
planned No No
SEC-CP End-User Authentication
planned No No
OS-CP Vehicle Interface planned No No
The use of the RIs and of the additional software components is shown in Figure 5.
Figure 5: Reference Implementations in the Client
Following figure shows how the implemented components are used in sequence:
30/09/2006 9 Version 2.0

D4.3 Description of Stuttgart lab prototypes
Figure 6: CRL Request considering as example for implemented components
3.2.3 Client System Lab Test Site Applications
In the following some details and snapshots about the implementations of the lab test
site applications (Stuttgart test cases) will be shown.
3.2.3.1 Client System Management Safeguarding
As described in [1] the safeguarding of a Client System Management takes care of legal
operations on client side. The Client System Management Safeguarding on the client side
consists of the three sub-services
A. Secure Service Provisioning
B. Certificate Management
C. Security Component Management
The Stuttgart Lab Test Site focuses on Certificate Management in which three functionalities
were implemented
o Certification Revocation List (CRL) Update
o Root Certificate Update
o Certification Update
Sub-services A. and C. are not integrated because provisioning of services is not implemented
in the lab test site.
3.2.3.2 Client side implementation
The following class diagram gives an insight into the class structure used for the client
side implementation of the Client System Management Safeguarding. It visualizes the
used classes and functions already mentioned in Figure 6. Due to simplification and better
overview the amount of the functions listed has been reduced (only Security Module,
Secure Storage and User Interface).
Explanation:
30/09/2006 10 Version 2.0

D4.3 Description of Stuttgart lab prototypes
• The GUI package (org.gstproject.sec.secmodule.client.gui.impl at the bottom)
works as a simple function trigger and for visualization/logging of the whole
communication process. The triggered functions are the three Certificate Management
functions of the Security Module.
• To implement the Certificate Management functionality into the Security Module,
it had to be extended by three additional functions which realize the interaction
with the CAAccessHandler and finally integrate the Certificates and CRL into the
keystore handled by the Security Module
• The communication between Security Module and the SimpleCA is realized by
the CAAccessHandler using the Reference Implementation of the Connection
Manager for the establishment of the necessary SOAP connection. CAAccessHandler
adds a new abstraction layer onto the connection to SimpleCA to offer
a consistent programming interface even if low-level interfaces (Connection Manager,
Secure Communication Engine, etc.) changes.
30/09/2006 11 Version 2.0

Figure 7: Class diagram of CSMS client implementation
D4.3 Description of Stuttgart lab prototypes
30/09/2006 12 Version 2.0

Progress Bars
D4.3 Description of Stuttgart lab prototypes
In the following some screenshots of the Vehicle Front-end User interface are shown.
The interfaces enables the user to specifically trigger Certificate Management functions,
get immediately feedback about the progress and see the detailed logging entries if necessary.
Trigger Buttons
Log entry
Figure 8: CSMS Vehicle Front-end Interface (e.g., CRL Update Failed / Root Cert Update OK)
30/09/2006 13 Version 2.0
Results

D4.3 Description of Stuttgart lab prototypes
Figure 9: CSMS Vehicle Front-end Interface (e.g., Complete Update of Certificates and CRL)
30/09/2006 14 Version 2.0

Figure 10: CSMS Logging Interface
3.3 Control Centre
D4.3 Description of Stuttgart lab prototypes
3.3.1 Control Centre Software and Hardware Configuration
The Stuttgart Lab Test Site uses the following software and hardware for the control centre
systems:
o Standard Desktop PC Pentium IV
o Operating System Debian Linux 2.6.x
o Java virtual machine: Java 1.5.0_05-b05
o Web Server: Tomcat 5.x
o WebService Server-Plug-in: Axis 1.3.x
o GST Reference Implementations: see chapter 3.3.2
o Services: The Service which is used from the Control Centre is the Certification
Authority, which is based on the Open Source Implementation EJBCA
[3], see also 3.3.3
30/09/2006 15 Version 2.0

D4.3 Description of Stuttgart lab prototypes
3.3.2 GST Reference Implementations
The following GST Reference Implementations are used in the Control Centre:
Test Site Stuttgart
GST / SP Interfaces used RI used
[Yes/No]
SP-TC
used
[Yes / No]
ETS used
[Yes / No]
Explanation
SEC-CP Certificate Management
Yes Yes Yes
SEC-CP Security Module Yes Yes Yes Small modifications
of RI Security
Module to include
certificate management
SEC-CP Simple Open CA Yes Yes Yes
SEC-CP Secure Communication
Engine
planned No No
The use of the RIs and of the additional software components is shown Figure 11.
Figure 11: Reference Implementations in the Control Centre
30/09/2006 16 Version 2.0

3.3.3 Control Centre Lab Test Site Application
3.3.3.1 Control Centre Implementation
D4.3 Description of Stuttgart lab prototypes
The following class diagram gives an insight into the class structure used for the server
side implementation of the Client System Management Safeguarding. It visualizes the
used classes and functions already mentioned in Figure 6. The system is designed to operate
from within the Control Centre, not in a Service Centre, intentionally.
Explanation:
• The CAAccessService is an implementation of a web service. This functionality is
established by using the Apache Tomcat Servlet Engine and the Apache AXIS
Servlet for enabling Tomcat talking the SOAP protocol. The CAAccessService
represents the external interface of the SimpleCA. It uses the three classes CertRequestHandler,
CRLFactory and RootCAHandler to offer certificate management
functionality to external clients systems
• The classes CertRequestHandler, CRLFactory and RootCAHandler are again an
additional abstraction layer. They offer the Certificate Authority functionality to
the other Control Centre applications and “hide” the complex CA system behind
their defined interfaces. The CA system behind the scenes is in case of the Test
Site Stuttgart the open source implementation EJBCA [3] which is described
later.
30/09/2006 17 Version 2.0

Figure 12: Class diagram of Simple Open CA implementation
3.3.3.2 Certification Authority (EJBCA)
D4.3 Description of Stuttgart lab prototypes
EJBCA is an advanced open source CA-implementation written in a Java/J2EE environment.
The focus for the EJBCA project is to create a flexible, platform independent
and scalable CA/RA solution, fulfilling various requirements a large enterprise could
have, concerning not only security aspects but also connectivity, administrative delegation
and event logging. For current information about the EJBCA project, see
http://www.ejbca.org/.
The Stuttgart Lab Test Site uses EJBCA not only for the handling of the Certificate
Management, but also for Registration Authority (RA) purposes. The following screenshot
show the creation for possible templates of new certificates and the editing of entity
profiles, which specify basic parameters for issued certificates.
30/09/2006 18 Version 2.0

Figure 13: EJBCA - First part of a certificate profile.
Figure 14: EJBCA - Second Part of a certificate profile
D4.3 Description of Stuttgart lab prototypes
30/09/2006 19 Version 2.0

Figure 15: EJBCA - First part of an entity profile
Figure 16: EJBCA - Second part of an entity profile
D4.3 Description of Stuttgart lab prototypes
30/09/2006 20 Version 2.0

D4.3 Description of Stuttgart lab prototypes
3.4 Testing/Monitoring and Remote Vehicle Diagnosis
Together with the University of Furtwangen we have organized a so-called “Student project”.
The goal of this student project was that a group of students (currently 5 students)
should learn the basics of project-management by working in a “real” project. The task in
our GST based project was the conception and the implementation of a GST compliant
prototype application (“Vehicle Diagnosis and Application Testing/Monitoring”) and the
applications had to be based on the available GST Reference Implementation.
The results of the student project was the creation of a Monitoring-/Diagnosis application
enabling a secure requesting transmitting and storing of vehicle data for analysing
purposes during the development and testing cycles of a vehicle. The application consists
of basically five parts, three on the client side and two on the server (Monitoring Center)
side.
Client:
Server:
- MessageHandler
- Vehicle (Simulated)
- Vehicle-GUI
- Monitoring-Web-Service
- Monitoring-Web-Frontend
In the following the sequence of the application in detail is described:
Figure 17: Sequence diagram of Vehicle Diagnosis Application
30/09/2006 21 Version 2.0

D4.3 Description of Stuttgart lab prototypes
First when the vehicle is started, meaning the Vehicle-API is loaded, the Vehicle initializes
all its components and checks for all available components. After this initialization
process the Vehicle uses the MessageHandler to connect to the Monitoring Center and
to register the vehicle to the system and announce its availability. Due to security reasons
it was decided that no communication from infrastructure to the car was allowed; only
vice versa, meaning you can't connect to the car but the car can connect to you. Hence, a
polling mechanism was implemented. The vehicle connects in to the Monitoring Center
in a specific interval, to receive new information which then can be processed. Types of
information can be for example the message to turn on/off the monitoring mode or to
send data of a specific sensor to the Monitoring Center. The vehicle sensor data shown
in Figure 19 are only simulated (there is no mapping of the Vehicle –API to vehiclesensor-data
implemented)
The purpose of the Vehicle-GUI is to simply visualize the current data of the available
vehicle sensors (see Figure 19).
Figure 18: Implemented VehicleAdminTree for the Vehicle Diagnosis Application
30/09/2006 22 Version 2.0

Figure 19: Vehicle GUI on the Client Side
D4.3 Description of Stuttgart lab prototypes
On the side of the Monitoring Center a web service has been implemented. This service
enables the clients (vehicles) to register themselves to the "Available for Monitoring" Database
and to transmit the sensor data if requested. The data is stored within a traditional
SQL database and therefore available for further analysis.
An additional function of the web service is that clients can send a query to the implemented
message queue to see if there are any new messages available. This queue buffers
the already mentioned messages like "TURN ON MONITORING" for the clients due
to the uncertainty of their availability and polling intervals.
The monitoring web front-end is basically a simple management interface to visualize the
available vehicle data and to queue additional message for specific cars (see Figure 20).
The monitoring web front-end offers the ability to select a vehicle from the "cars available"
list. After the selection the already collected information of the vehicle is displayed
in the main frame. The small form underneath the vehicle information, offers the ability
to submit new orders/messages to the queue resp. to the client.
30/09/2006 23 Version 2.0

Figure 20: Web-Interface of the Monitoring Center
3.5 Live-CD
D4.3 Description of Stuttgart lab prototypes
Due to portability the complete Stuttgart Lab Test Site has been ported to a set of two
live-cds. These CD's are based on the linux distribution "Slax" (http://slax.org) which is
a very flexible livecd-platform for x86 systems. One CD includes the Certificate Management
and Vehicle-API Implementation and represents the mobile part of our lab test
site (see Figure 21 and Figure 22). It allows us to span our test over a much bigger environment,
without the need of additional installations and configurations, just by booting
the CD on a certain amount of PC's. The creation of the SimpleCA livecd was a logical
result of Certificate Management livecd (see Figure 23). It offers the opportunity to give
the SimpleCA implementation to the project partners, who then can test their implementation
together with a working SimpleCA, without the need of installation and complex
configuration.
30/09/2006 24 Version 2.0

Figure 21: Live-CD Certificate Management (Knopflerfish)
Figure 22: Live-CD Certificate Management (CSMS-GUI)
D4.3 Description of Stuttgart lab prototypes
30/09/2006 25 Version 2.0

Figure 23: Live-CD Simple Open-CA
D4.3 Description of Stuttgart lab prototypes
30/09/2006 26 Version 2.0

D4.3 Description of Stuttgart lab prototypes
Chapter 4 - CONCLUSIONS AND NEXT STEPS
The prototypical implementation described in version 2.0 of this deliverable is finished.
All results and descriptions of the outcome of the Student project (the student project
was finished mid of July 2006) are also included.
30/09/2006 27 Version 2.0

REFERENCES
D4.3 Description of Stuttgart lab prototypes
[1] Jürgen Wojatschek, et. al.: “DEL_4_1 Stuttgart Technical Description of Prototype”.
Deliverable DEL_TS_4_1, Global System for Telematics GST, FP6-2002-
IST-1-507033, October 2005.
[2] Jürgen Wojatschek, et. al.: “DEL_5_1 Stuttgart Preparation of Test Site”. Deliverable
DEL_TS_5_1, Global System for Telematics GST, FP6-2002-IST-1-507033,
March 2006.
[3] EJBCA, http://www.ejbca.org/
[4] Stephan Eichler, et. al.: “DEL_3_1 GST SEC Architecture and Interface Specifications”,
DEL_SEC_3_1, Global System for Telematics GST, FP6-2002-IST-1-
507033, September 2005.
30/09/2006 28 Version 2.0