schmittlauch/hs-pseudonym-schemes-in-v2x
1
0
Fork 0
Code Issues 1 Pull requests Releases Wiki Activity

identifiers for GeoNetworking, certs and BTP

Browse source
This commit is contained in:
Trolli Schmittlauch 2018-06-06 22:51:32 +02:00
parent d35df3f15b
commit 996d11bfd8
5 changed files with 48 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

37
main.tex
View file

@ -183,7 +183,7 @@ CALM FAST \cite{TN_libero_mab2} is a non-IP port-mapper protocol designed for si
\acf{GN} (\cite{europeantelecommunicationsstandardsinstituteetsiETSI30263612014} and following) is an \ac{ETSI}-standardized networking protocol for routing and forwarding packets through \acp{VANET} based on geographical Information. It sits between the link and network layer and provides its services to other networking and transport protocols. The background section of \cite{sandonisVehicleInternetCommunications2016} gives a good high-level overview of the \ac{GN} networking architecture and the rationale behind it.
Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS}), for the routing to work. The services provided by \ac{GN} are:
Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS}, for the routing to work. The services provided by \ac{GN} are:
\begin{itemize}
\item geo-unicast: routing a packet to a single node at a specific location
@ -218,16 +218,45 @@ If \ac{IPv6} over \ac{GN} is used at the network layer, transport protocols like
\subsection{Identifiers}
There are many different addresses, IDs or other identifying information scattered around the network layers. This sections gives a list of these identifiers and the information encoded in them.
There are many different addresses, IDs or other identifying information scattered around the network layers. This sections gives a list of relevant identifiers and the information encoded in them. Media-dependent additional identifiers are considered out-of-scope.
\subsubsection{GeoNetworking}
Each \ac{GN} node is identified by a \ac{GN} address
Each \ac{GN} node is identified by a 64bit GN\_ADDR address \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}, containing information about the \ac{ITS} station type (passenger car, cyclist, pedestrian, \ac{RSU}, …) and 48bit derived from the link-layer address. In case of a pseudonym change, only the latter part is supposed to change.
\ac{GN} packets have a basic, a common and an optional extended header.
\begin{figure}
\includegraphics[width=0.47\textwidth]{figures/GeoNetworking_structure.png}
\caption{structure of an unsecured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
\label{fig:GNstructure}
\end{figure}
As shown in fig. \ref{fig:GNstructure}, \ac{GN} packets have a basic, a common and an optional extended header. The \textit{basic header} contains information like the packet's maximum lifetime and the remaining hop limit. These information are non-critical for identification. The \textit{common header} also doesn't contain identifying, only the flag indicating a mobile or stationary \ac{ITS} station could slightly reduce the anonymity set. The \textit{extended header} fields depend on the actual \ac{GN} package type and can contain information like the sequence number (initialized with 0) and position vectors.
The \ac{LT} is populated with information from beaconing messages and all other messages received by the \ac{ITS} node. \acl{LT} entries also contain identifying data: Additionally to the GN\_ADDR, station type and link-layer address of the peer node it contains a timestamped geographical position (including accuracy), its current speed and its heading. \todo{update position/ reacquire it when changing pseudonym}
\begin{figure}
\includegraphics[width=0.47\textwidth]{figures/GeoNetworking_structure_secured.png}
\caption{structure of a secured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
\label{fig:GNstructure_secured}
\end{figure}
Parts of \ac{GN} packets can be secured by wrapping them into security headers as defined in \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1032017} as shown in fig. \ref{fig:GNstructure_secured}. This service is provided by the vertical security layer in the \ac{ETSI} \ac{ITS} architecture and secures all parts shown in fig. \ref{fig:GNstructure_secured} between security header and trailer according to the chosen security profile. The standard defines security profiles for encrypted, signed, externally signed, and signed encrypted messages.
The certificates used contain information about signer subject (name, type, keys), validity restrictions and the actual certificate signature from the \ac{CA}.
The signer information can be given in form of a digest, certificate or certificate chain.
The security trailer contains a signature for verifying authenticity and integrity of the message.
\todo{sequence number initialized with 0}
\todo{packet buffers: LS, forwarding}
\subsubsection{BTP}
The \ac{BTP} header as defined in \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636512017} is only 4 bytes long and has a quite simple structure. \\
There are 2 modes of operation for BTP: \textit{interactive packet transport} using the BTP-A header, meant for services requiring replies to their messages, and \textit{non-interactive packet transport} using the BTP-B header.
The BTP-A header consists out of 2 16bit numbers denoting the source and destination ports. The BTP-B header contains the 16bit long destination port and 16bit for optional destination port information (depending on the service).
Some of the facility layer services have well-known ports assigned in \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1032016}, so the destination port might identify the service used.
\section{Pseudonym Schemes}
\subsection{Pseudonym Schemes for ETSI ITS Systems}