1. Cédric Bonhomme
  2. ubiroads-paper

Commits

Cédric Bonhomme  committed 018a699

Removed trailing spaces.

  • Participants
  • Parent commits 46fa730
  • Branches default

Comments (0)

Files changed (1)

File 2012-UBIROADS-TUDOR.tex

View file
  • Ignore whitespace
-    \documentclass[conference]{IEEEtran}
+\documentclass[conference]{IEEEtran}
 \usepackage[pdftex]{graphicx}
 \graphicspath{{./images/}}
 \DeclareGraphicsExtensions{.jpg,.jpeg,.png}
 authentication of the users and of the application components with the system.
 \end{abstract}
 
-\begin{IEEEkeywords}            
+\begin{IEEEkeywords}
 Multi-Agent System, Carpooling, Mobile authentication, Mobility services,
 Dynamic carpooling, Service Oriented Architecture
 \end{IEEEkeywords}
 %
 \section{Introduction} \label{sec_introduction}
 
-WiSafeCar~\cite{wisafecar} is an European project focusing on 
+WiSafeCar~\cite{wisafecar} is an European project focusing on
 researching and prototyping efficient car-to-car and car-to-infrastructure
 networking mechanisms in order to provide a support layer to a wide range of
 services to the users on the move, whether they are in their car or simply
-walking by. 
+walking by.
 WiSafeCar uses state of the art car-to-car networking protocols --
-such as IEEE 802.11p and an efficient service oriented architecture. 
+such as IEEE 802.11p and an efficient service oriented architecture.
 The services to be provided range from security related services such as
 geo-localized hazardous weather information to a dynamic urban transport
 solution reacting in real time to the status of the traffic and to disrupting
 on the specific security part of the system, including mutual authentication of
 the users, authentication of the pluggable services and protection of the data
 exchanged on the WiSafeCar network.
-We first present 
+We first present
 the high level services provided by the carpooling
 platform in Section~\ref{sec_wisafecar-security-platform}, focusing on the
-security implications. 
+security implications.
 Section~\ref{sec_description_of_the_carpooling_service} highlights the
 technologies used to provide dynamism to the carpooling service and depicts
 in details the implemented architecture.
 %
 \section{WiSafeCar Service Platform} \label{sec_wisafecar-security-platform}
 The dynamic carpooling is part of the WiSafeCar Service Platform which is build on top of
-the wireless communication platform. 
-This one provides an infrastructure to a wide range of commercial and governmental transport and traffic services. 
+the wireless communication platform.
+This one provides an infrastructure to a wide range of commercial and governmental transport and traffic services.
 In Luxembourg, WiSafeCar
 offers innovative and efficient multi modal urban transport services. Among those, the
 Dynamic Carpooling service allows an efficient trip planning for drivers and passengers
 For that a prior agreement between the relevant parties is required.
 
 In order to provide as much flexibility as possible, the SOP is connected to
-the Multi-Agent System thanks to a specific kind of distributed agents. 
+the Multi-Agent System thanks to a specific kind of distributed agents.
 This specific architecture will be described more in details in the rest of the
 paper.
 
 \label{sec_description_of_the_carpooling_service}
 
 The dynamic carpooling service relies on several ancillary services to provide a
-quick reaction to change in the context and unforeseen events. 
+quick reaction to change in the context and unforeseen events.
 These services are mainly the \emph{Location Tracing Service}, the
 \emph{Security Service} and the \emph{External Road Traffic Information
-service}. 
+service}.
 They are represented on 
 Fig.~\ref{fig_wsc-platform} and are described more in details in the
 following paragraphs.
 account and a new planning is provided to the affected users directly on
 their terminal. Moreover, a monitoring tool is also implemented in order
 to enable real time reaction to unforeseen traffic event and correct as
-soon as possible the recommendation made to the users. 
+soon as possible the recommendation made to the users.
 
 \subsection{Location tracing service}
 In Luxembourg,
 tightly disconnected from the rest of the system and is subject to the
 user -- through the application running on its mobile phone -- voluntarily
 sending position updates when he detects an event possibly impacting his
-planning. 
+planning.
 There is no direct link between the data sent by the mobile application and the
 identity of the user.
 Moreover, the actual solution has been developed in the form of several
 content exchanged between actors of the platform is the so called
 \emph{transaction data}.
 A transaction is a formalism borrowed from the finance
-domain~\cite{2003Khadraoui,2004Feltus}. 
+domain~\cite{2003Khadraoui,2004Feltus}.
 It is a message consisting in all the information required to characterize a
-trip realized by one of the user of the system. 
+trip realized by one of the user of the system.
 It can for instance contain information regarding the Unique IDentifier (UID)
 of a passenger, the one of the driver, the distance traveled in one specific
 car, the duration of the trip.
 \subsection{Mobile application}
 In the dynamic carpooling prototype, each user owns a mobile terminal -- namely
 a smartphone -- running the WiSafeCar application.
-This application is composed of several pluggable components. 
+This application is composed of several pluggable components.
 The guidance module is based on Navit open source project~\cite{navit}, and
 provide a GPS based navigation application, guiding the user through his
 planning but also allowing to send events and alerts to the platform.
 The mutual authentication module is triggered automatically once two users
-participating to the same trip are in the vicinity from each other. 
+participating to the same trip are in the vicinity from each other.
 This module allows assessing the respective identity of these users.
 Each device also embeds a personal agent, whose task is to "represent" this
 specific device and its owner within the platform.
 
 \subsection{Multi-agent service architecture}
 Figure~\ref{fig_multi-agent-architecture} presents the global
-architecture of the multi-agent platform used within WiSafeCar. 
+architecture of the multi-agent platform used within WiSafeCar.
 As we can see it consists of a network of interconnected agents located between
 the clients and the SOA platform.
 Communications are bidirectional, external services are able to send
 a notification to a subset of users (for example based on their location)
-through the SOA architecture and the MAS. 
+through the SOA architecture and the MAS.
 This architecture is highly scalable and able to easily include new services:
 geolocalized meteorological information, infotainment services, etc.
 
 Moreover these agents are responsible to store localization
 information locally, when the connection to the main platform is unavailable,
 which can happen quite often on a loosely connected network such as a VANET or
-a MANET. 
+a MANET.
 
 The second class of agents,
 the remote agents, are disseminated all over the networks and
 
 Finally, the keystore agent controls the public keys repository of all the clients of the WiSafeCar platform.
 The keystore agent is in charge of delivering public keys (that are embedded in
-vCards) when a local agent requests it. 
+vCards) when a local agent requests it.
 This agent is crucial for the security of the communications. For instance, it
 can be used to simply revoke the access of a malicious client.
 It is one of the main elements of the security components that are described in
 Indeed there is a high chance that the planning algorithm will ask two persons
 that do not know each other to share the same car for instance.
 Subsequently, it is especially important to provide a way for the involved user
-to asses their respective identity. 
+to asses their respective identity.
 This assessment is done via the \emph{mutual authentication service}.
 
 Other more typical threats have also been identified and taken into account in
 component is able to take care of several authentication tasks at once
 since it relies on a client-server architecture: passengers (clients)
 request the authentication service from one driver (server). If the
-authentication is successful, a visual clue is displayed. 
+authentication is successful, a visual clue is displayed.
 Figure~\ref{fig_mutual-authentication} present a example of the
 proof-of-concept authentication interface implemented on Android.
 
 certificate and some other information is stored (such as the Bluetooth MAC
 address).
 The private key and the \emph{Root Certificate} key must be known by each
-user. 
+user.
 The authentication is based on challenge-response. Each device creates
 random data and send it to the other participant who must sign the
 received data and send back the computed hash. The first participant just has
 architecture.
 Several clients (passengers) ask for a service (authentication) to one server (driver).
 The server side starts loading the personal data from the vCards of all the
-clients that are supposed to share the same car. Subsequently, it starts to 
+clients that are supposed to share the same car. Subsequently, it starts to
 listening to incoming connection from the list of allowed MAC address read out
-of the vCards. 
+of the vCards.
 The clients try to connect and if its Bluetooth MAC address is in server's list
 the connection is granted.
 After a connection granted, the procedure is the same than in the single driver
 \subsection{Authentication of a transaction in a MAS Network}
 Each transaction supported by the MAS network is authenticated and encrypted.
 Obtaining a signed public key is mandatory for each actor trying to send
-something on the network. 
+something on the network.
 Figure~\ref{fig_getting-a-public-key}
 depicts how Bob will get the public key of Alice in order to send secured
 and authenticated messages. The keystore agent is responsible for the keys of all
 The requester will keep the public keys stored locally during all the trip.
 Thus, in this example, Bob will be able to
 send encrypted and signed messages to Alice. Alice will then be able to
-check the authenticity and decipher the message. 
+check the authenticity and decipher the message.
 As it is usually the case with asymmetric cryptography, data is encrypted with
 the public key of the recipient and signed with the private key of the sender.
 Additionally, a client without a key previously registered to the keystore agent