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

finished Background section

Browse source
This commit is contained in:
Trolli Schmittlauch 2018-06-07 13:12:29 +02:00
parent 996d11bfd8
commit 6fcb77fd6e
2 changed files with 25 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
glossary.tex
View file

@ -18,6 +18,8 @@
\acro{GNSS}{Global Navigation Satellite System}
\acro{GVL}{Geographical Virtual Link}
\acro{IPv6}{Internet Protocol version 6}
\acro{ITS}{Intelligent Transportation Systems}
@ -34,6 +36,8 @@
\acro{OSI}{Open Systems Interconnection}
\acro{RA}{Router Advertisement}
\acro{RSU}{road-site unit}
\acro{VANET}{vehicular ad-hoc network}

28
main.tex
View file

@ -172,7 +172,7 @@ The two vertical \textit{Management} and \textit{Security} layers provide suppor
\todo{participants, structure, special requirements: changing topology, speed, realtime}
Designed for modularity, the \ac{ETSI} \ac{ITS} architecture allows for a big number of access protocols. Similarly, a great variety of applications can run on top of the stack. Because of that variety, these two layers are considered out-of-scope of this survey.
Designed for modularity, the \ac{ETSI} \ac{ITS} architecture allows for a big number of access protocols. Similarly, a great variety of applications can run on top of the stack. Because of that variety, access and application layer are considered out-of-scope of this survey.
The \textbf{Networking \& Transport} layer takes care of addressing and routing of messages within the ITS network and multiplexing them to higher-level services. Similarly to the \ac{OSI} model, the groundwork of this functionality is provided by various networking protocols: \\
\ac{ETSI} explicitly mentions the usage of \ac{IPv6} (possibly equipped with mobility support), the CALM FAST protocol \cite{TN_libero_mab2} and the \acf{GN} protocol, which can also be used to encapsulate \ac{IPv6} packets.
@ -193,14 +193,14 @@ Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS
\item geo-anycast: routing packet to an arbitrary node within a specified geographical area
\end{itemize}
For this to work, each node maintains a \ac{LT} with the positions of its direct neighbours. This \ac{LT} is populated with information from periodically-sent beaconing messages, advertising a node's position, \ac{GN} address, its speed, station type \todo{check advertised information}. This information is also included in all other sent \ac{GN} packets. \ac{LT} entries have a lifetime attached, after which they expire if not refreshed periodically.
For allowing to retrieve the position of non-neighbour nodes, the \ac{LS} forwards request packets, until the node with the destination \ac{GN} address is found and has replied via geo-unicast or a retransmission counter has expired.\todo{influence of frequent pseudonym change}
For this to work, each node maintains a \ac{LT} with the positions of its direct neighbours. This \ac{LT} is populated with information from periodically-sent beaconing messages. These beacons advertise a node's position, \ac{GN} address, its speed, station type and heading (see \ref{GN-identifiers}. This information is also included in all other sent \ac{GN} packets. \ac{LT} entries have a lifetime attached, after which they expire if not refreshed periodically.
For allowing to retrieve the position of non-neighbour nodes, the \ac{LS}, a collaborative functionality of all nodes, forwards request packets, until the node with the destination \ac{GN} address is found and has replied via geo-unicast or a retransmission counter has expired.\todo{influence of frequent pseudonym change}
Security properties of \ac{GN} messages are ensured by signing (authenticity), encrypting (confidentiality) the messages and checking their plausability and consistency. The necessary information for that is given in a security header \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017}.
\subsubsection{IPv6}
\acsu{IPv6} \cite{RFC8200} \nocite{baeckerRFCE014IPv6} specifies the 6th version of the Internet Protocol, the routing protocol used in the Networking layer of the internet. Relevant details for \acp{VANET} are the addressing using 128 bit long IP addresses \cite{RFC4291} with the first up to 64 bits specifiying the network part and the last 64 bits specifying the interface ID (node ID) within that subnetwork. Additionally to the globally unique routable address, nodes are also addressable in the scope of the same \ac{OSI} layer 2 link using their link-local address automatically derived from lower-layer identifiers. Together with the huge number of globally unique \ac{IPv6} addresses, this new property makes it usable for vehicular ad-hoc networks. Another improvement in \ac{IPv6} is the \textit{router advertisement} \cite{RFC4861} of clients, where routers just periodically announce their parameters so clients are able to derive an address themselves without further negotiation.
\acsu{IPv6} \cite{RFC8200} \nocite{baeckerRFCE014IPv6} specifies the 6th version of the Internet Protocol, the routing protocol used in the Networking layer of the internet. Relevant details for \acp{VANET} are the addressing using 128 bit long IP addresses \cite{RFC4291} with the first up to 64 bits specifiying the network part and the last 64 bits specifying the interface ID (node ID) within that subnetwork. Additionally to the globally unique routable address, nodes are also addressable in the scope of the same \ac{OSI} layer 2 link using their link-local address automatically derived from lower-layer identifiers. Together with the huge number of globally unique \ac{IPv6} addresses, this new property makes it usable for vehicular ad-hoc networks. Another improvement in \ac{IPv6} is \textit{neighbour discovery} \cite{RFC4861} using link-local multicast. One application of that is the \textit{\acf{RA}}, where routers just periodically announce their parameters so clients are able to derive an address themselves without further negotiation.
\subsubsection{IPv6 over GeoNetworking}
@ -214,13 +214,18 @@ The transport layer protocol above \acl{GN} is the \acf{BTP} \cite{europeantelec
If \ac{IPv6} over \ac{GN} is used at the network layer, transport protocols like TCP and UDP from the standard internet protocol suite can of course be used, too.
\todo{facilities layer, management and security layer too?}
The \textbf{Facilities Layer} unifies the three upper \ac{OSI} layers (application, presentation, session layer) and provides different support tasks to services and applications like time management, position management, database management and session management. It is also responsible to manage service priorities when passing down data to the Network and Transport Layer.
The \textbf{Security Layer} is a vertical layer providing security functionality like identity, key and certificate management to all other layers. It also executes all cryptographic functions like encryption or verification of data.
The \textbf{Management Layer} takes care of software changes like updates and installation of additional components and is considered out-of-scope of this survey.
\subsection{Identifiers}
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}
\label{GN-identifiers}
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.
@ -235,7 +240,7 @@ As shown in fig. \ref{fig:GNstructure}, \ac{GN} packets have a basic, a common a
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}
\includegraphics[width=0.49\textwidth]{figures/GeoNetworking_structure_secured.png}
\caption{structure of a secured \ac{GN} packet, source: \cite{hamidaSecurityCooperativeIntelligent2015}}
\label{fig:GNstructure_secured}
\end{figure}
@ -245,7 +250,7 @@ Parts of \ac{GN} packets can be secured by wrapping them into security headers a
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.
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}
@ -257,6 +262,15 @@ There are 2 modes of operation for BTP: \textit{interactive packet transport} us
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.
\subsubsection{IPv6}
While each IPv6-capable network interface can have multiple addresses, it has at least one link-local address with the interface ID (the lower 64bits) uniquely derived from its data-link layer address. The mapping of IPv6 link-local address and GN\_ADDR is straight-forward, as both addresses are deterministically derived from the same 48bit link layer address. Additionally to the IPv6 address, the IPv6 header can also contain a 20bit \textit{flow label} which could lead to partial linkability of packets even after an address change.
There exists a static mapping between IPv6 multicast groups and geographical areas (relative to the station). That means it is possible to contact IPv6-based services within a node's surrounding. But as this mapping is static and relative, it shouldn't help reidentifying hosts.
\acfp{GVL} are another important concept for understanding the visibility scope of IPv6 packets to other nodes. These virtual links are defined as non-overlapping, restricted geographical areas wherein all IPv6 multicasts within the same subnet are forwarded via \ac{GN} to all nodes of that \ac{GVL}. Usually this is a zone around a specific \ac{RSU} serving as an internet uplink and thus managing the whole subnet and its addresses. Globally routable IPv6 addresses are usually obtained via the stateless autoconfiguration with the help of \acp{RA}. So changing the \ac{GVL} means getting another IPv6 prefix announced via \ac{RA} and thus implies a change in the node's global IPv6 address.
There are no obvious identifiers specified in the Facilities layer, though some might be introduced in real-world implementations.
\section{Pseudonym Schemes}
\subsection{Pseudonym Schemes for ETSI ITS Systems}