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

spellcheck

Browse source
This commit is contained in:
Trolli Schmittlauch 2018-06-10 16:13:22 +02:00
parent 3d3f31b7ad
commit 12f378cf1f
2 changed files with 17 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
glossary.tex
View file

@ -20,6 +20,7 @@
\acro{MAC}{Medium Access Control}
\acro{OBU}{On-Board Unit}
\acro{OSI}{Open Systems Interconnection}
\acro{PKI}{Public Key Infrastructure}
\acro{RA}{Router Advertisement}
\acro{RSU}{Road-Site Unit}
\acro{V2X}{Vehicle-to-Everything}

30
main.tex
View file

@ -83,7 +83,7 @@
\Hide{
1) Problem statement: The Problem (one is more than sufficient for each paper!)\\
2) Relevance: Why ist this problem /really/ a problem?\\
2) Relevance: Why is this problem /really/ a problem?\\
3) Response: What is our solution to the problem?\\
4) Confidence: how do we show in this paper, that our solution is good?
}
@ -154,7 +154,7 @@ This section gives a brief overview of the \ac{ETSI} architecture for Intelligen
\acp{VANET} have some special requirements: Due to many nodes being constantly on the move at higher speeds, tolerance for quickly changing topologies and low-latency communication are important points. Multi-hop mesh-networking is an important ability to keep the network functional in areas without designated infrastructure.
A \ac{VANET} consists of different kinds of ITS stations: \\
\acfp{OBU} residing inside vehicles can be divided into the communication and \acl{CCU}, managing the \ac{ITS} specific network communication over the car's wireless interfaces, and \acfp{AU} utilising the network services provided by the \ac{CCU} to communicate transparently over a standard \acs{IPv6} stack. \\
\acfp{OBU} residing inside vehicles can be divided into the communication and \acl{CCU}, managing the \ac{ITS} specific network communication over the car's wireless interfaces, and \acfp{AU} utilizing the network services provided by the \ac{CCU} to communicate transparently over a standard \acs{IPv6} stack. \\
On the stationary infrastructure side, \acfp{RSU} can either just provide some special local services or even be connected to a network operator's infrastructure and thus provide an uplink to the Internet.
\begin{figure}
@ -177,7 +177,7 @@ The protocol architecture of \ac{ITS} stations according to the \ac{ETSI} refere
\ac{OSI} layers 1 and 2 are combined into the \textit{Access} layer, \ac{OSI} layers 3 and 4 into the \textit{Networking \& Transport} layer and \ac{OSI} layers 5, 6 and 7 are put into the \textit{Facilities} layer (see Fig. \ref{fig:etsi-its-arch} ). \\
The two vertical \textit{Management} and \textit{Security} layers provide supporting functionality throughout the whole stack. \textit{Applications} make use of the \ac{ITS}-station services and thus sit on top of it all.
\todo{participants, structure, special requirements: changing topology, speed, realtime}
\todo{participants, structure, special requirements: changing topology, speed, real-time}
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.
@ -203,11 +203,11 @@ Every \ac{GN} node has to know its geographical position, e.g. through \acp{GNSS
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}.
Security properties of \ac{GN} messages are ensured by signing (authenticity), encrypting (confidentiality) the messages and checking their plausibility 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 IPv6 address, nodes are also addressable with their link-local address. This special address is only valid in the scope of the same \ac{OSI} layer 2 link and is 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.
\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 specifying the network part and the last 64 bits specifying the interface ID (node ID) within that subnetwork. Additionally to the globally unique routable IPv6 address, nodes are also addressable with their link-local address. This special address is only valid in the scope of the same \ac{OSI} layer 2 link and is 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}
@ -292,7 +292,7 @@ A widely chosen approach for restoring user privacy is the usage of temporary ps
\nocite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}The \ac{ETSI} standard on trust and privacy management \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022012} mentions the goal of pseudonymity and unlinkability of \ac{ITS} nodes and their messages as the way to achieve ITS privacy. This privacy goal is subdivided into two dimensions:
The \textbf{privacy} of ITS registration and authorisation shall be achieved by limiting the knbowledge of a node's canonical (fixed) identifier to a limited number of authorities. Furthermore, the responsibility for verifying the validity of a canonical identifier is given to an \acf{EA} and split from the authorisation to services by the \acf{AA}. These both authorites need to be operated in different areas of control to achieve a surplus of privacy.\\
The \textbf{privacy} of ITS registration and authorization shall be achieved by limiting the knowledge of a node's canonical (fixed) identifier to a limited number of authorities. Furthermore, the responsibility for verifying the validity of a canonical identifier is given to an \acf{EA} and split from the authorization to services by the \acf{AA}. These both authorities are parts of the needed \ac{PKI} and need to be operated in different areas of control to achieve a surplus of privacy.\\
During manufacture the following data is to be stored in an ITS node using a physically secure process:
\begin{itemize}
\item a globally unique canonical identifier
@ -301,24 +301,24 @@ During manufacture the following data is to be stored in an ITS node using a phy
\item a network address
\item a set of trusted \ac{EA} and \ac{AA} certificates
\end{itemize}
The \ac{EA} has to hold the following information about a node: The permanent canonical identifier, its enrolment credentials, its public key and a link to further profile information.
ITS nodes can now request an enrolment certificate with their enrolment credentials from the EA. The task of the \ac{EA} is to verify that an \ac{ITS} node can be trusted to function correctly as the EA must only know the credentials of certified \ac{ITS} nodes. Credentials of compromised nodes have to be revoked. With the enrolment request being encrypted and signed by the enrolling node and the response being encrypted as well, only the \ac{EA} knows the mapping between the enrolment certificate and the requesting identity. The enrolment certificate contains a pseudonymous identifier being signed with a certificate chain leading back to the originating \ac{EA}.
This enrolment certificate can then be used to get \acfp{AT} from an \ac{AA}. These \acp{AT} too are certificates denoting the permissions a node has. \\
The \ac{EA} has to hold the following information about a node: The permanent canonical identifier, its enrollment credentials, its public key and a link to further profile information.
ITS nodes can now request an enrolment certificate with their enrolment credentials from the EA. The task of the \ac{EA} is to verify that an \ac{ITS} node can be trusted to function correctly as the EA must only know the credentials of certified \ac{ITS} nodes. Credentials of compromised nodes have to be revoked. With the enrollment request being encrypted and signed by the enrolling node and the response being encrypted as well, only the \ac{EA} knows the mapping between the enrollment certificate and the requesting identity. The enrollment certificate contains a pseudonymous identifier being signed with a certificate chain leading back to the originating \ac{EA}.
This enrollment certificate can then be used to get \acfp{AT} from an \ac{AA}. These \acp{AT} too are certificates denoting the permissions a node has. \\
All authority responses are encrypted and signed in a for the node verifiable way. Certificate requests include a start and end time as well as a \textit{challenge} \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010}, a random string encrypted with the public key of the receiver. These two measures prevent against message replay attacks. Enrolment credentials and \acp{AT} can also be updated if needed over similar mechanisms.
The second dimension of privacy covers the communication between \ac{ITS} stations. The obtained authorization tickets serve as pseudonyms for authenticating and signing messages with other \ac{ITS} services and nodes. ITS stations have to check the validity of the \ac{AT} certificates included in every message and can check the permissions for the message's action (e.g. sending messages to certain broadcast domains) or access to certain services. These pseudonyms are to be regularly changed to preserve the privacy of the node's user by achieving long-term unlinkability of messages by the ITS node. According to \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636412017} the \ac{AT} may even be used to derive a \ac{GN}\_ADDR from.\\
There are differnt kinds of \acp{AT}: Those used by official role vehicles (e.g. state authorities) and \ac{ITS} infrastructure don't need to preserve the node's privacy and thus can contain a long-lived identifier for the official role they are fulfilling. \acp{AT} of personal user nodes can contain further personal identifying information if required for service usage, but then shall only be sent to already authorized nodes over encrypted channels.\todo{restrict this only to services where this is really necessary} For broadcasting, first contact and all other uses, personal user nodes shall only use minimal pseudonymous \acp{AT} which then can be sent even over non-encrypted channels.
There are different kinds of \acp{AT}: Those used by official role vehicles (e.g. state authorities) and \ac{ITS} infrastructure don't need to preserve the node's privacy and thus can contain a long-lived identifier for the official role they are fulfilling. \acp{AT} of personal user nodes can contain further personal identifying information if required for service usage, but then shall only be sent to already authorized nodes over encrypted channels.\todo{restrict this only to services where this is really necessary} For broadcasting, first contact and all other uses, personal user nodes shall only use minimal pseudonymous \acp{AT} which then can be sent even over non-encrypted channels.
The \ac{ETSI} standard \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010} mentions the retaining of an audit log of incoming messages as the way of holding nodes \textbf{accountable} in case of misbehaviour. This only helps though if the \ac{EA} retains a mapping of enrolment certificate to the canonical identifiers they were given to and the \ac{AA} does the some for \acp{AT} and enrolment certificates. The legal and organisatorial framework for making sure that the information from the \ac{EA} and \ac{AA} are only combined for legitimate cases is crucial for maintaining user privacy, but are left out-of-scope of this survey.
The \ac{ETSI} standard \cite{europeantelecommunicationsstandardsinstituteetsiETSITS1022010} mentions the retaining of an audit log of incoming messages as the way of holding nodes \textbf{accountable} in case of misbehaviour. This only helps though if the \ac{EA} retains a mapping of enrollment certificate to the canonical identifiers they were given to and the \ac{AA} does the some for \acp{AT} and enrolment certificates. The legal and organisational framework for making sure that the information from the \ac{EA} and \ac{AA} are only combined for legitimate cases is crucial for maintaining user privacy, but are left out-of-scope of this survey.
For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of misbehaviour, there exist multiple mechanisms: The \ac{EA} can be told to revoke the node's enrolment credentials to prevent it from updating its enrolment certificate and thus acquiring further \acp{AT}. Additionally, the \ac{EA} revokes the validity of the enrolment certificate and the \ac{AA} does the same for the authorization tickets. As ITS nodes are expected to check the validity of certificates using \acfp{CRL} and \acfp{CTL} \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018}, messages of the revoked node are not accepted anymore.
For \textbf{revocation} of node access to the \ac{ITS} network, e.g. in case of misbehaviour, there exist multiple mechanisms: The \ac{EA} can be told to revoke the node's enrollment credentials to prevent it from updating its enrollment certificate and thus acquiring further \acp{AT}. Additionally, the \ac{EA} revokes the validity of the enrollment certificate and the \ac{AA} does the same for the authorization tickets. As ITS nodes are expected to check the validity of certificates using \acfp{CRL} and \acfp{CTL} \cite{europeantelecommunicationsstandardsinstituteetsiETSITR1032018}, messages of the revoked node are not accepted anymore.
\subsubsection{Pseudonym Change for IPv6 ITS Networking}
Section 11 of the \ac{ETSI} standard on IPv6 usage over \ac{GN} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} covers the support for pseudonymes and their change of that protocol stack. The binding of a \ac{GVL}'s prefix to a distinct geographical area can be a threat to users' location privacy as a static interface identifier part of the IPv6 address would allow singling out a node over multiple \ac{GVL} networks and track their location by the \ac{GVL} prefix and its associated geographical region. \\
The proposed countermeasure is again the adoption and regular change of pseudonyms. In this case the affected identifier is the interface identifier part of IPv6 address. As this identifier is derived from the link-layer address, this also implies a change of the link-layer identifier address (MAC address). The same is true for the \ac{GN}\_ADDR thus it also changes accordingly with the changed link-layer address. All existing IPv6 addresses have to be terminated as a clear cut between the old and new pseudonym IP address has to be made to prevent correlation of the old and new pseudonym during migration. A possible countermeasure against the interruption is the usage of \textit{Network Mobility support} \cite{RFC3963}. As this mobility support requires a home agent where all traffic flows through, this home agent needs to be trusted as it still has the possibility of loction tracking by \ac{GVL}.
Section 11 of the \ac{ETSI} standard on IPv6 usage over \ac{GN} \cite{europeantelecommunicationsstandardsinstituteetsiETSI302636612014} covers the support for pseudonyms and their change of that protocol stack. The binding of a \ac{GVL}'s prefix to a distinct geographical area can be a threat to users' location privacy as a static interface identifier part of the IPv6 address would allow singling out a node over multiple \ac{GVL} networks and track their location by the \ac{GVL} prefix and its associated geographical region. \\
The proposed countermeasure is again the adoption and regular change of pseudonyms. In this case the affected identifier is the interface identifier part of IPv6 address. As this identifier is derived from the link-layer address, this also implies a change of the link-layer identifier address (MAC address). The same is true for the \ac{GN}\_ADDR thus it also changes accordingly with the changed link-layer address. All existing IPv6 addresses have to be terminated as a clear cut between the old and new pseudonym IP address has to be made to prevent correlation of the old and new pseudonym during migration. A possible countermeasure against the interruption is the usage of \textit{Network Mobility support} \cite{RFC3963}. As this mobility support requires a home agent where all traffic flows through, this home agent needs to be trusted as it still has the possibility of location tracking by \ac{GVL}.
\subsection{Further Pseudonym Techniques}
\subsection{Further Pseudonym Scheme Techniques}
\subsection{Pseudonym Change Strategies}