AUTOPSY: A Framework for Tackling Privacy Challenges in the Automotive Industry
Extracted source text · arXiv 2507.16788
% This is samplepaper.tex, a sample chapter demonstrating the
% LLNCS macro package for Springer Computer Science proceedings;
% Version 2.21 of 2022/01/12
%
\documentclass[runningheads,orivec]{llncs}
%
\usepackage[T1]{fontenc}
% T1 fonts will be used to generate the final print and online PDFs,
% so please use T1 fonts in your manuscript whenever possible.
% Other font encondings may result in incorrect characters.
%
\usepackage{graphicx}
% Used for displaying a sample figure. If possible, figure files should
% be included in EPS format.
%
% If you use the hyperref package, please uncomment the following two lines
% to display URLs in blue roman font according to Springer's eBook style:
%\usepackage{color}
%\renewcommand\UrlFont{\color{blue}\rmfamily}
%\urlstyle{rm}
%
\usepackage[numbers,sort&compress]{natbib}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{algorithmic}
\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{comment}
\usepackage{microtype}
\usepackage{xcolor}
\usepackage{tabularx}
\usepackage{array} % For advanced table formatting
\usepackage{multirow} % For merging rows in tables
\usepackage{colortbl} % For coloring cells
\usepackage{graphicx} % For rotating text (e.g., \rotatebox)
\usepackage{pifont} % For checkmark (\checkmark)
\usepackage{subcaption}
\usepackage[misc,geometry]{ifsym}
\usepackage[hyphens]{url}
\usepackage[obeyFinal]{todonotes}
\newcommand{\todoConti}[2][]{\todo[inline,color=cyan!40, #1]{Todo Conti: #2}}
\newcommand{\todoSP}[2][]{\todo[inline,color=green!40, #1]{Todo SP: #2}}
\newcommand{\todoSS}[2][]{\todo[inline,color=blue!60, #1]{Todo SS: #2}}
\newcommand{\todoMauH}[2][]{\todo[inline,color=blue!30, #1]{Todo MauH: #2}}
\newcommand{\todoMatH}[2][]{\todo[inline,color=yellow!40, #1]{Todo MatH: #2}}
\newcommand{\todoAMG}[2][]{\todo[inline,color=yellow!40, #1]{Todo AMG: #2}}
\newcommand{\todoBC}[2][]{\todo[inline,color=brown!40, #1]{Todo Badr: #2}}
\newcommand{\todoAB}[2][]{\todo[inline,color=magenta!40, #1]{Todo Anis: #2}}
\newcommand{\todoAAT}[2][]{\todo[inline,color=gray!40, #1]{Todo Abedeljalil: #2}}
\newcommand{\todoRY}[2][]{\todo[inline,color=teal!40, #1]{Todo Reda: #2}}
\newcommand{\todoNN}[2][]{\todo[inline,color=red!40, #1]{Todo: #2}}
\newcommand{\discuss}[2][]{\todo[inline,color=red!40, #1]{Discuss: #2}}
\usetikzlibrary{positioning,fit,arrows.meta,backgrounds}
\begin{document}
%
\title{AUTOPSY: A Framework for Tackling Privacy Challenges in the Automotive Industry}
%
\titlerunning{AUTOPSY: A Framework for Privacy in the Automotive Industry}
% If the paper title is too long for the running head, you can set
% an abbreviated paper title here
%
\author{Sebastian Pape \textsuperscript{\Letter} \inst{1,2}\orcidID{0000-0002-0893-7856} \and
Anis Bkakria\inst{3}\orcidID{0000-0002-9758-4617} \and
Maurice Heymann\inst{1}\orcidID{0009-0008-5603-8653} \and
Badreddine Chah\inst{4}\orcidID{0009-0003-2665-8679} \and
Abdeljalil Abbas-Turki\inst{4}\orcidID{0000-0002-4443-0542} \and
Sarah Syed-Winkler\inst{1}\orcidID{0000-0002-3197-9456} \and
Matthias Hiller\inst{5}\orcidID{0000-0003-1238-1114} \and
Reda Yaich\inst{3}\orcidID{0000-0001-7294-5909}}
%
\institute{Continental Automotive Technologies GmbH, Frankfurt, Germany, \email{firstname.lastname@continental.com}
\and
Goethe University Frankfurt, Germany
\and
IRT SystemX, Palaiseau, France
\and
CIAD UR 7533, UTBM, Belfort, France
\and
Fraunhofer AISEC, Garching, Germany
}
\authorrunning{S. Pape et al.}
% First names are abbreviated in the running head.
% If there are more than two authors, 'et al.' is used.
%
\maketitle % typeset the header of the contribution
%
\begin{abstract}
With the General Data Protection Regulation (GDPR) in place, all domains have to ensure compliance with privacy legislation. However, compliance does not necessarily result in a privacy-friendly system as for example getting users' consent to process their data does not improve the privacy-friendliness of the system. Therefore, the goal of the AUTOPSY project was to support the privacy engineering process in the automotive domain by providing several building blocks which technically improve the privacy-friendliness of modern, i.\,e., connected and (partially) automated vehicles.
This paper presents the results of the AUTOPSY project: a system model to identify relevant entities and locations to apply privacy enhancing technologies (PETs); the privacy manager aiming at more control of the data flow from the vehicle, a PET selection approach based on GDPR principles, and an architectural framework for automotive privacy. Furthermore, we built a demonstrator for location-based services to evaluate the architectural framework.
\keywords{privacy engineering\and automotive privacy\and pet selection\and privacy-enhancing technologies\and demonstrator}
\end{abstract}
%
%
%
\section{Introduction}\label{sect:introduction}
%From Proposal
Faster and faster innovation cycles in the IT and electronics industry lead to new global trends such as IoT, cloud, or AI that change several aspects of our daily lives. For example, in the transportation domain, trends such as autonomous driving, e-mobility and shared mobility will significantly impact our ways of life towards more safety, quality of life, and sustainability.
The development and deployment of connected vehicles, smart car applications and automotive services (mobility, traffic and parking management, etc.) relies on the generation, processing and sharing of unprecedented amounts of data. This need is further exacerbated in the context of autonomous driving vehicles wherein data, that needs to be shared with other vehicles, the infrastructure, and remote services hosted in the Cloud, is of particular importance.
On the other hand, the automotive industry has also a track of extensive privacy policies~\cite{PTKSP18ifipsec} as recently investigated by the Mozilla foundation\footnote{\url{https://foundation.mozilla.org/en/privacynotincluded/categories/cars/}} and huge data leakages\footnote{cf.\ https://media.ccc.de/v/38c3-wir-wissen-wo-dein-auto-steht-volksdaten-von-volkswagen}%\footnote{https://www.techradar.com/vehicle-tech/hackers-expose-serious-subaru-security-flaws-that-allow-them-to-remotely-start-cars}
, especially of location data.
From the regulatory side, the General Data Protection Regulation (GDPR)~\cite{gdpr} is a huge step forward. However, often companies dealing with data are afraid of being incompliant and see the regulations as a hurdle that needs to be overcome instead of a baseline that represents the absolute minimum for privacy~\cite{ABMPPB24iwpe}. However, compliance with the data protection regulation does not automatically
equal ethical organizational procedures~\cite{tronnier2022discussion} or results in a privacy-friendly system: I.\,e., having a customer sign an end user license agreement that grants the right to process sensitive data, does not solve the underlying issue of actually protecting the data.
Therefore, there is the need to ensure privacy on a technical level: privacy enhancing technologies (PETs) need to be integrated into the real-world information systems engineering process~\cite{pallas2024privacy}.
Focus of this paper is to share the lessons we learned during the project, compare them to results of similar work and derive future work. For that purpose, we briefly introduce the results of the project, which mostly are covered in more detail in the referenced work.
The remainder of the paper is as follows: The remainder of Sect.~\ref{sect:introduction} summarizes the project's goal, contribution and specific use cases. Sect.~\ref{sect:results} describes the results of the AUTOPSY project and Sect.~\ref{sect:evaluation} its evaluation. Sect.~\ref{sect:discussion} discusses lessons learned, connects the results to related work and discusses limitations and future work. Sect.~\ref{sect:conclusion} concludes the paper.
\subsection{Goal and Contribution of the AUTOPSY Project}
The goal of the AUTOPSY project was to provide technical solutions improving the privacy engineering processes of systems in the automotive domain. Our focus was on practical applicability in real-world information systems~\cite{pallas2024privacy}.
This paper contributes several technical building blocks to improve the privacy of connected and partially autonomous vehicles:
a system model to identify relevant components and places to apply privacy enhancing technologies (PETs); the privacy manager, a system aiming at controlling the data flow from the vehicle; a PET selection approach based on GDPR principles; and a framework for automotive privacy.
%tailored PETs to the automotive use cases considered in the project;
% and a demonstrator for location-based services built on the framework.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Use Cases Focused on by AUTOPSY poject}
Our project covers four use cases:
\subsubsection{Usage-Based Insurance (UBI)}
% what is the Pay as you drive insurance?
%The automotive insurance industry, represented by companies such as Progressive Corporation\footnote[1]{Source: \url{https://www.progressive.com/}} and Mobilize Insurance\footnote[2]{Source: \url{https://www.mobilize-fs.com/fr/actualites/pay-you-drive-et-pay-how-you-drive-nos-premieres-offres-dassurance-connectee}}, is actively improving its billing practices to reward safe driving behavior with reduced premiums. This approach, known as Usage-Based Insurance (UBI), differs from traditional vehicle insurance. The main goal of this service is to charge the customers based on usage and driving habits, such as mileage, speed, acceleration, and driving time.
%The two most common types of UBI are “Pay-As-You-Drive” (PAYD) and “Pay-How-You-Drive” (PHYD). PAYD primarily focuses on the total distance driven, while PHYD evaluates additional aspects such as speed, braking, acceleration, and the time of day a vehicle is driven (for further details, see \cite{tselentis2016innovative}). This personalized approach aims to align insurance costs with individual driving behaviors. High-risk drivers face higher premiums, whereas safe and cautious drivers benefit from lower rates. As a result, UBI contributes to reduced insurance costs and enhanced driving safety \cite{bian2018good}.
% What kind of data do you need to run your services?
%For UBI, to accurately calculate premiums based on driving behavior, insurance companies must collect real-time driving data from their customers. This information, often deemed highly sensitive, is typically gathered, processed, and analyzed by insurers, sometimes without robust access controls in place. Given the vast data generated by connected vehicles (CVs) which goes up to 500 GB per hour in fully connected scenarios \cite{Go}.
%To meet GDPR's legal stipulations, the insurance company must ensure that its development systems respect client privacy following these principles.
% How the AI is used in UBI
%Artificial Intelligence (AI) offers significant advantages for Usage-Based Insurance, revolutionizing driver profiling with innovative and efficient approaches. AI systems excel at processing vast amounts of data, extracting meaningful insights, and automating complex or repetitive tasks. Moreover, they can learn from new data and adapt their behavior over time\footnote[3]{Source: \url{https://medium.com/@careervira.community/most-important-advantages-and-disadvantages-of-machine-learning-in-2024-9d56ee451622}}. This adaptability is particularly useful for classifying drivers based on their behavior—such as cautious, average, or risky—a process referred to as driver profiling. Within the broader field of AI, machine learning (ML) is especially recognized for its capabilities in classification, making it a critical tool for advancing UBI services.
% One of the most effective approaches reducing road accidents is to identify risky driving behaviors. In this use case, we focus on a specific Usage-Based Insurance (UBI) model, where users pay premiums based on their driving behavior. More specifically, we investigate a scenario in which the developed models leverage Advanced Driver Assistance Systems (ADAS) to detect hazardous driving patterns and utilize vehicle connectivity to update the driver profiling model dynamically. However, a major challenge lies in promoting safe driving behavior without discouraging users from adopting the service due to concerns over privacy breaches and potential punitive measures. Another key issue is ensuring that the driver profiling models are highly accurate, allowing users to understand how their insurance premiums are calculated.\\
% Among AI techniques, machine learning-based classification appears to be the most suitable for this task \cite{10.1007/978-3-031-66428-1_34}. Additionally, federated learning (FL) is particularly well-suited for updating these models, as it allows decentralized learning to update the model without directly sharing user data. However, despite FL often being considered privacy-preserving, many studies highlight its vulnerabilities to privacy attacks \cite{NEURIPS2021_08040837,10.1145/3510032,9546481}.
% Thus, a critical challenge is the integration of PETs into FL, ensuring that the models remain both highly accurate and privacy-compliant. The goal is to classify drivers effectively while preventing the exposure of sensitive personal data.
Identifying risky driving behaviors is key to reducing road accidents. This Usage-Based Insurance (UBI) use case focuses on Pay-As-You-Drive Insurance\footnote{UBI Source: \url{https://www.mobilize-fs.com/fr/actualites/pay-you-drive-et-pay-how-you-drive-nos-premieres-offres-dassurance-connectee}} type, where premiums depend on driving behavior. We explore how Advanced Driver Assistance Systems (ADAS) detect hazardous driving and use vehicle connectivity to dynamically update driver profiles. However, balancing safety incentives with privacy concerns remains a challenge, as is ensuring accurate driver profiling for fair premium calculation.
Machine learning-based classification is well-suited for this task~\cite{10.1007/978-3-031-66428-1_34}, with federated learning (FL) enabling decentralized model updates without directly sharing user data. However, FL is vulnerable to privacy attacks~\cite{NEURIPS2021_08040837,10.1145/3510032,9546481}.
The key challenge is integrating PETs into FL to maintain both accuracy and privacy, ensuring effective driver classification without exposing sensitive data.
\subsubsection{Platooning}
Platooning \cite{platooning} is a technique close to fully automated driving, where a so-called platoon leader drives a route and permits other vehicles to join the platoon and follow by driving autonomously, which is more convenient and also efficient. The use case requires the vehicles to have a basic set of sensors to sense the environment, cruise control and lane-keep assistance and positioning including a high-definition map.
Leaders announce their routes, and followers privately compute their own, verifying leader trustworthiness before joining. While a server can facilitate this, platooning is possible without one. During operation, V2X messages manage smooth merging, departures, and route deviations. The main privacy challenge is to form a platoon without revealing sensitive information about participants' vehicles.
% The leaders communicate each that they are willing to lead a platoon and their routes. In the next step, the followers compute the routes in a privacy preserving way and query the trustworthiness of the potential leaders to a server. Then, they decide to join a platoon. In principle, platooning can also be performed without a server without including a rating on the platoon leader.\\
% During operation, an exchange of a V2X message ensures a smooth operation to also manage merging of platoons, leaving of members and deviations from the initially planned route. One critical aspect is the liability of a platoon leader if any damage occurs to a follower.
% The main privacy challenge of this use case is in the platoon selection process: The vehicle needs to find a suitable platoon leader, without both sharing their entire route.
\subsubsection{Silent Testing}
Silent testing is a testing method that utilizes data from automated vehicles in a customer fleet. \citet{wangsilent} summarizes the key concepts of silent testing. We refer to silent testing as the monitoring of a System under Test (SuT) in real-world conditions on public roads, without controlling the vehicle’s actuators.% or interfering with safety-critical systems.
A human driver or automated driving system performs the driving task while the SuT is running, but neither the driver nor passengers actively participate in the monitoring. These restrictions ensure that no safety risks are posed. A primary use case of the collected data is safety validation of the vehicle, but it can also contribute to continuous software improvement or provide training data for neural networks. Data collections in silent testing vary significantly depending on the specific monitoring and development goals.\\
The main privacy challenge of this use case is to have meaningful data available for the software improvement or training and validation of machine learning algorithms while limiting the use of that data to derive other insights (not needed for the primary purpose) in parallel.
\subsubsection{Location-Based Service}
% The Location-Based Service (LBS) delivers personalized, location-based services to users, including route optimization, nearby recommendations, and contextual information, enhancing the overall user experience. LBS rely on real-time GPS and user preferences to deliver relevant and timely information. These services leverage data from user devices to provide dynamic, location-aware features, enabling users to make informed decisions based on their surroundings.
% To deliver accurate and personalized location-based services, the LBS provider (LBSP) must first collect and process specific data from each user’s device. The following data types are typically gathered. First, current position: Real-time GPS data to determine the user’s current location. Second, direction of movement: Directional data helps the LBSP in anticipating user needs based on current heading and possible upcoming stops. Last but not least, user query specification: The user can submit a specific query indicating desired information or preferences for nearby points of interest. This query may include details such as type of venue (e.g., restaurants, parks, shopping centers), type of service, or other context-driven requests that allow the LBSP to tailor responses according to the user’s expressed needs.
Location-Based Services (LBS) provide personalized, location-aware services such as route optimization, nearby recommendations, and contextual information to enhance the user experience. LBS rely on real-time GPS and user preferences to offer timely, relevant data. To deliver accurate services, the LBS provider (LBSP) collects and processes data from users, e.\,g.\ current position (GPS data), direction of movement (to anticipate needs), and user queries (preferences for points of interest like restaurants or parks).\\
The reliance of LBS on continuous real-time location data collection brings inherent privacy challenges for users. The sensitive nature of location information can expose users to risks if mismanaged, including potential tracking of movement patterns and revealing personal routines.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% RESULTS %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 3 pages %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{AUTOPSY results}\label{sect:results}
Our results contribute to various areas of privacy engineering. In the design phase our system model is supporting the identification of relevant entities and suitable locations to integrate PETs in modern vehicle architectures (cf.\ Sect.~\ref{sect:result_systemmodel}). In the same manner, the privacy manager (PM) provides an abstract concept to control the application flow inside the vehicle (cf.\ Sect.~\ref{sect:result_privacymanager}). When specific requirements, i.\,e.\ the GDPR principles have been identified, we support also the selection of suitable PETs (cf.\ Sect.~\ref{sect:result_petselection}).
Bringing this altogether, we designed a framework for automotive privacy (cf.\ Sect.~\ref{sect:result_framework}) which we then implemented (cf.\ Sect.~\ref{sect:evaluation_framework}) and instantiated in form of a demonstrator (cf.\ Sect.~\ref{sect:evaluation_demonstrator}) for evaluation.
\subsection{Architectural Concept}
The architectural concept consists of the system model used for analysis, the privacy manager as a concept to enforce data flows, and a proposal how to technically enforce purpose limitation.
\subsubsection{System Model}\label{sect:result_systemmodel}
We contribute to the field of privacy-by-design in vehicles with a generic system model for the purpose of identifying the relevant entities, data flow and spotting suitable locations to apply PETs. The system model consists of several dimensions to allow capturing different notions: An overview for the relation of the entities with a fine-grained level definition (cf.\ Fig.~\ref{fig:scenario_all}), functional and topological In-Vehicle-Architecture, a communication model, a trust model, and a data classification~\cite{PSGCBHWLAY23cscs}. Our evaluation by applying the system model and the PM to two distinct use cases shows that our approach is feasible and supports the integration of privacy.
\begin{figure}[tb]
\centering
\includegraphics[width=\linewidth]{figures/Scenario_All_v2.png}
\caption{System Model Overview~\cite{PSGCBHWLAY23cscs}}\label{fig:scenario_all}
%\Description{The figure shows a car which interacts with a service provider and another road user, within the car there is an icon for the In-Vehicle-Architecture and the car connects to devices depicted as mobile phone and a remote smartkey}
\end{figure}
\subsubsection{Privacy Manager}\label{sect:result_privacymanager}
A subsequent contribution is the concept of our PM, which supports applications in the implementation of PETs or enforces a certain data flow avoiding that information is leaked
%in an avoidable way
~\cite{PSGCBHWLAY23cscs}.
%facilitates the use of PETs in applications and makes it easier to distinguish raw data computations from application logic.
Fig.~\ref{fig:framework} depicts an abstracted view of the vehicle's architecture. We assume that the PM and potential applications are running in an high-performance computing platform (HPC). There are four different modes in the vehicle for operating with the PM: i) The application has \emph{direct access} to the required data. ii) The application communicates with the PM over an API to \emph{apply PETs} on the required data. iii) The application requests data from the PM, which only delivers the result of a \emph{computation on raw data} and not the raw data itself. iv) A \emph{combination} of PET application and computation on raw data.
%\begin{figure}[tbh]
% \centering
% \includegraphics[width=\linewidth]{figures/System_Model_v2_5.png}
% \caption{System Model Communication}\label{fig:systemmodelcar2}
% \Description{The figure shows the communication model of a vehicle. The communication bus connects sensors, actuators, obd II and the infotainment system to standalone ECUs and the gateway. The gateway connects standalone ECUs, the commnication bus, the TCU and the HPC. The HPC consists of the privacy manager who is connecte to applications and libraries and the gateway and TCU. The TCU connects the cloud with the HPC and the gateway.}
%\end{figure}
\subsubsection{Technically Enforcing Purpose Limitation}\label{sect:results_purpose}
There are two components to the principle of purpose limitation: i) personal data must only be collected for specified, explicit, and legitimate purposes; ii) the collected data cannot be used for a different or incompatible purpose. %For scientific or historical research or even statistical purposes, exceptions can be made.
%Initially, transparency on the intention is required, which \citet{koning2016purpose} defines as 'purpose specification'. Second, she demands binding to predetermined conditions, or 'use limitations'.
The use of encryption is one technical way to restrict access only to those entities who process data for the specified purpose: Only entities with legitimate purposes are able to decrypt (selected) personal data to prevent entities who do not process data for the stated purpose from processing. This allows the controller to monitor if entities receive the decryption key, which enables them to access specific data. We propose a method how to technically enforce purpose limitation using Attribute-Based Encryption (ABE)~\cite{SPS22cscs}.
\subsection{Supporting PET Selection}\label{sect:result_petselection}
We support the ability to select candidate PETs tailored to specific use cases based on GDPR principles~\cite{gdpr}. Fig.~\ref{fig:PET_Selection_Overview} provides an overview of the necessary steps. As preparation (blue steps, outside of the scope of our framework),
the use case needs to be described, involved entities need to be identified along
with the established trust model. The next steps (in green) are in the focus of our
framework: Based on the trust model, relevant GDPR principles are identified
(step 3, cf. Sect.~\ref{sect:result_petselection_1}). The GDPR principles are then mapped to PET types (step
4, cf. Sect.~\ref{sect:result_petselection_2}) to identify candidate PETs that can be applied to enforce the selected
principles. Furthermore, we provide an assessment of the maturity of PETs with
regards to utility, scalability, and robustness to support the PET selection process
(step 6, cf. Sect.~\ref{sect:result_petselection_3}). Finally, trade-offs between utility, privacy, and efficiency need to be done specifically for the use case (outside of scope of our framework).
\begin{figure}[tb]
\centering
\includegraphics[width=.75\linewidth]{figures/PET_Selection_Overview.png}
\caption{PET Selection Overview~\cite{PBCHS25ares}}\label{fig:PET_Selection_Overview}
%\Description{The figure shows a car which interacts with a service provider and another road user, within the car there is an icon for the In-Vehicle-Architecture and the car connects to devices depicted as mobile phone and a remote smartkey}
\end{figure}
\subsubsection{Trust Model vs. GDPR principles}\label{sect:result_petselection_1}
We considered two dimensions: \textit{i) Relevance} of the principle, which does not imply that there are not relevant principles, but that in each trust model some may be more relevant than others. \textit{ii) Accountability} which refers to the entity's capability to not only follow the principle but also provide some evidence.
\subsubsection{Mapping GDPR principles to PETs}\label{sect:result_petselection_2}
% PETs can be applied in four layers: the physical layer (vehicles with sensors and communication systems), the network layer (data transmission via technologies like dedicated short range communication and cellular networks), the data/process layer (data storage and processing, where privacy concerns arise), and the business layer (leveraging processed data for decision-making, optimization, and services). Selecting the PET type for each layer requires mapping of GDPR principles to these technologies. To achieve this, we align the GDPR principles with the different layers (see Table \ref{GDPR_To_PETs}).
% It is evident that adhering to GDPR principles cannot be achieved by focusing on a single layer alone. Each layer can address specific GDPR principles based on the PETs implemented in it and how they are combined.
PETs apply across four layers: \textbf{Physical} (vehicles with sensors and communication), \textbf{Communication} (data transmission via DSRC and cellular networks), \textbf{Processing} (processing of data inside and outside the vehicle), and \textbf{Storage} (storage of data, in particular, outside of the vehicle). Choosing PETs requires mapping GDPR principles to these layers (see Table \ref{GDPR_To_PETs}). In Table \ref{GDPR_To_PETs}, the green check indicates that most PET types effectively address this specific GDPR principle, while the yellow check suggests that their applicability may vary depending on the utilization context and use case. Compliance cannot rely on a single layer; each contributes by implementing and combining PETs accordingly.
% \begin{itemize}
% \item \textbf{Physical Layer}: PETs such as Attribute-Based Encryption (ABE), Local Differential Privacy (LDP), and pseudonymisation help uphold GDPR principles such as purpose limitation, data minimisation, and integrity and confidentiality.
% \item \textbf{Network Layer}: PETs like authentication, digital signatures, and anonymity support GDPR principles such as data minimisation, integrity, and confidentiality.
% \item \textbf{Processing Layer}: This layer is the focus of our analysis, where various PETs are examined to align with GDPR principles such as purpose limitation, data minimisation, and integrity and confidentiality.
% \item \textbf{Business Layer}: PETs such as Trusted Execution Environment (TEE) use encryption to protect sensitive data and ensure data deletion after a certain period. TEE address the GDPR principle of storage limitation, as well as purpose limitation, data minimisation, integrity and confidentiality. However, these techniques rely on the service provider's control over the hardware.
% \end{itemize}
The physical layer uses PETs like Attribute-Based Encryption (ABE), Local Differential Privacy (LDP), and pseudonymisation to support GDPR principles such as purpose limitation, data minimisation, and confidentiality.
The communication layer relies on authentication (i.e., digital signatures), encryption, and anonymity for data minimisation, integrity and confidentiality, and accountability. The processing layer is the most interesting layer for using PETs to address GDPR principles like purpose limitation and data minimisation. Furthermore, Trusted Execution Environments (TEE) can be used to protect the confidentiality and integrity of processed data. In the storage layer, it can also be used to ensure deletion and address storage limitation, though it depends on the service provider's hardware control. Additionally, encryption can be used, i.e., ABE allows the enforcement of purpose limitation.
\begin{table}[tb]
\centering
\begin{tabularx}{\columnwidth}{|l|l|X|X|X|X|X|X|X|}
% \hline
% \multicolumn{9}{|c|}{\textbf{Mapping of PETs to GDPR Principles}} \\
\hline
\textbf{Layer} & \textbf{PET Type} & \rotatebox{90}{\textbf{L/F/T}} & \rotatebox{90}{\textbf{PL}} & \rotatebox{90}{\textbf{DM}} & \rotatebox{90}{\textbf{A}} & \rotatebox{90}{\textbf{SL}} & \rotatebox{90}{\textbf{I/C}} & \rotatebox{90}{\textbf{Acc}} \\
\hline
\hline
\multirow{2}{*}{\textbf{Physical}}
& Anonymity-based & & & \cellcolor{green!25} \checkmark & & & & \\\cline{2-9}
& Cryptography-based & & \cellcolor{green!25} \checkmark & \cellcolor{green!25} \checkmark & & & \cellcolor{green!25} \checkmark & \\
\hline
\hline
\multirow{3}{*}{\textbf{Communication}}
& Anonymity-based & & & \cellcolor{green!25} \checkmark & & & & \\ \cline{2-9}
& Authentication-based & & & & & & \cellcolor{green!25} \checkmark & \cellcolor{green!25} \checkmark \\ \cline{2-9}
& Cryptography-based & & & & & & \cellcolor{green!25} \checkmark & \\ \cline{2-9}
\hline
\hline
\multirow{3}{*}{\textbf{Processing}}
& Anonymity-based & & & \cellcolor{green!25} \checkmark & & & & \\ \cline{2-9}
& Cryptography-based & \cellcolor{yellow!25} \checkmark & \cellcolor{green!25} \checkmark & \cellcolor{green!25} \checkmark & & & \cellcolor{green!25} \checkmark & \\ \cline{2-9}
& Traceability & \cellcolor{yellow!25} \checkmark & \cellcolor{yellow!25} \checkmark & \cellcolor{green!25} \checkmark & & & & \cellcolor{yellow!25} \checkmark \\
\hline
\hline
\textbf{Storage}
& Cryptography-based & & \cellcolor{green!25} \checkmark & \cellcolor{green!25} \checkmark & & \cellcolor{yellow!25} \checkmark & \cellcolor{green!25} \checkmark & \\\cline{2-9}
& Immutability & \cellcolor{green!25} \checkmark & & & & & \cellcolor{green!25} \checkmark & \cellcolor{green!25} \checkmark \\
\hline
\multicolumn{9}{c}{}\\%to fix vertical spacing
\end{tabularx}
\caption{Mapping of GDPR (Article 5) Principles to PET Types.\\\textbf{L/F/T}: Lawfulness, Fairness, and Transparency; \textbf{PL}: Purpose Limitation;\\\textbf{DM}: Data Minimization; \textbf{A}: Accuracy; \textbf{SL}: Storage Limitation\\\textbf{I/C}: Integrity and Confidentiality; \textbf{Acc}: Accountability }
\label{GDPR_To_PETs}
\end{table}
\subsubsection{Maturity comparison}\label{sect:result_petselection_3}
We performed a comparative analysis of existing PETs, revealing their effectiveness, robustness, scalability, and suitability for low-computation power devices.
The assessed maturity level can be used to decide about the practical applicability for the shortlisted PETs. Our analysis identified key PETs, such as LDP \cite{yang2024local} and FL \cite{mcmahan2017communication} as optimal choices for our use cases due to their adaptability.
\subsection{Automotive Privacy Framework}\label{sect:result_framework}
Across the studied use cases, a \textbf{Three-party Model} emerges as an adaptable framework for privacy-preserving data processing:
\begin{itemize}
\item \textbf{Vehicle / User} – The end-user who selects and installs applications or services requiring access to vehicle data.
\item \textbf{Third party: intermediate servers} – Collect and perform data processing without direct access to private information, leveraging, e.\,g., encryption and secure multi-party encryption.
\item \textbf{Service Providers} – Utilize data provided by intermediate servers to deliver services.
\end{itemize}
This structure is similar to the Distributed Aggregation Protocol (DAP) \cite{ietf-ppm-dap-14}, which can be considered a three-party model where aggregators (i.\,e., intermediate servers) process data securely. Like DAP, strong security requirements are imposed on intermediate servers, ensuring they do not collude with each other, the service provider, or malicious users.
However, notable differences in data processing emerge between distinct use cases, such as data aggregation, personalized computations, credential issuance, verification, etc. These differences highlight the challenge of the lack of a unified protocol that fully addresses the specificities of different use cases, despite the structural similarities among the models.
Within the Automotive system, there are several key entities that interact to ensure secure and privacy-preserving data access for applications (cf.\ Fig.~\ref{fig:framework}):
\begin{figure}[tp]
\centering
\includegraphics[width=\textwidth, clip, trim={.75cm .75cm .6cm .75cm}]{figures/Framework_impl.pdf}
\caption{Framework Architecture}\label{fig:framework}
\end{figure}
\begin{itemize}
\item \textbf{App Manager}: Responsible for retrieving the selected application and extracting its \textit{manifest}, which contains metadata about the data types required by the app.
\item \textbf{Manifest}: Contains information about the data an App requires, which PETs are supported, and the data constraints such as the precision (e.g., resolution of location, amount of noise added to temperature etc.).
\item \textbf{Privacy Manager}: A central component that enforces privacy policies. It receives the app’s manifest, determines necessary \textit{PETs} to protect sensitive data, and generates privacy rules that regulate the data flow per data type.
\item \textbf{Pub-Sub Service}: Service that allows access to data items from their respective sources, i.e., \textit{sensors, Electronic Control Units (ECUs), and the Telematics Control Unit (TCU)}. These services act as intermediaries to retrieve raw data.
\item \textbf{Privacy-Enhancing Technologies (PETs)}: Mechanisms applied to data (e.g., anonymization, encryption, differential privacy) to ensure compliance with privacy policies before sharing data with applications. These \textit{PETs} are designed to be generic and OS-independent.
\end{itemize}
% To ensure privacy-preserving and controlled data access within the vehicle domain, applications follow a structured process when enrolling and requesting data. When a user installs an application, the App Manager retrieves the app and extracts its \textit{manifest}. The PM analyzes the required data types, supported PETs and determines which privacy measures to apply.
% In general, we ensure the privacy of the data by applying ABE to every data, both for storing it on the Data Master and for providing data to the App. This ensures purpose-limitation, i.e., only authorized service providers can access the respective data. Additional PETs are being applied as described before.
% Later, when an app requests access to a specific data item, it queries the PM, which retrieves the corresponding privacy rules and determines the necessary \textit{PETs}. These \textit{PETs} are applied to the cached data that has been received from the pub-sub service which ensures that recent data is always available in real-time. Finally, the PM transmits the processed data securely to the application.
To ensure privacy and controlled data access within the vehicle domain, applications follow a structured process. When a user installs an app, the App Manager retrieves and analyzes its \textit{manifest}. The PM analyzes the required data types, supported PETs, and determines privacy measures. In general, ABE is applied to all data for storage and access control, ensuring purpose limitation where only authorized service providers can access it. Later, when an app requests data, the PM applies the relevant PETs to the cached data and transmits it securely, ensuring real-time availability and privacy protection.
While an App can individually send data to the service provider / App as described previously, we also support a data-lake approach by streaming updates to the Storage Servers. The Storage Servers always (as long as network access is given) provide (encrypted) sensor data meeting the service's individual constraints such as freshness, precision etc. These parameters are also defined within the App Manifest that is provided when the App Provider uploads it to an AppStore maintained by the trusted third-party (like an OEM). These data updates are bundled and the transmission has been optimized to reduce the required bandwidth while fulfilling the Apps' constraints. Data stored on the Storage Servers already has PETs applied according to the Manifest, for example one item could represent $ABE(DP(data))$ or $ABE(Mask(data))$. Consequently, multiple Apps that require identical data and utilize the same PETs can share the same data item, thereby reducing the storage costs on the servers and the communication costs for the vehicle.
In addition to this data lake approach, we support the processing of the encrypted data of the car in a privacy-friendly way, similar to DAP. However, in the context of this project, data processing extends beyond simple aggregation measures by incorporating additional techniques such as HE and Differential Privacy (DP).
\section{Evaluation}\label{sect:evaluation}
For the evaluation purposes, we implemented the automotive privacy framework described in the previous section and built a demonstrator for the specific use-case of location-based services (cf.\ Sect.~\ref{sect:evaluation_demonstrator}) on top of it. The use case we could also utilize to test our method supporting PET selection.
\subsection{Implementation of the Automotive Privacy Framework}\label{sect:evaluation_framework}
As described before, we implemented the three distinct parties "vehicle / user", "third party: intermediate servers", and "service providers". Within the implementation of the framework, it was necessary to tailor PETs to our automotive use cases:
For the location navigation use case, we extended basic location-based LDP to manage multifaceted privacy risks, including location, trajectory, and visited points of interest, while optimizing utility in continuous LBS interactions \cite{bkakria2024framework}. In the platooning use case, we build upon Homomorphic Encryption (HE) to design a privacy-preserving protocol for platoon group formation \cite{chah2023h3pc}, ensuring secure and efficient vehicle coordination while maintaining data confidentiality. For the UBI use case, we combine FL with LDP and HE to preserve the confidentiality of sensitive driver information while enabling effective machine learning model training and updates \cite{UBI_25}. This approach ensures privacy without compromising model accuracy and adaptability.
To technically enforce purpose limitation, we could utilize the ABE implementation
rabe\footnote{url{https://github.com/Fraunhofer-AISEC/rabe}}, a rust library implementing several Attribute Based Encryption (ABE) schemes.
\subsection{Demonstrator for Location-Based Services}\label{sect:evaluation_demonstrator}
To showcase the added value of our implemented framework, we use an application that instantiates a location-based service. This application enables users to query a location-based service for nearby points of interest (POIs) of a specific type, such as restaurants, fuel stations, or other relevant locations. When a query is sent by the user, the LBS service retrieves the user's location from the query and sends the nearby points of interest.
To interact with the LBS, the user must install the LBS app within the car’s system. Based on the requested data types, as depicted in Fig.~\ref{fig:app_install}, the PM evaluates and shows the privacy threats the user may encounter when interacting with the app. Building on these functional requirements and the necessary data set, the PM selects the optimal combination of PETs to achieve the best privacy-utility tradeoff. For the considered LBS application, the PM applies Differential Privacy (DP) using the Planar Isotropic Mechanism \cite{bkakria2024framework} to obfuscate the user's location before sharing it with the LBS app.
\begin{figure}[!t]
\centering
\begin{subfigure}[b]{0.4\linewidth}
\centering
\includegraphics[width=\textwidth]{figures/app_install.png}
\caption{UI of the Location-Based Service App}%
{{}}
\label{fig:app_install}
\end{subfigure}
\hfill
\begin{subfigure}[b]{0.55\linewidth}
\centering
\includegraphics[width=\textwidth]{figures/locations.png}
\caption{App’s UI Displaying Real and Obfuscated Locations}%
{{}}
\label{fig:locations}
\end{subfigure}
\vskip\baselineskip
\begin{subfigure}[b]{\linewidth}
\centering
\includegraphics[width=\textwidth]{figures/loss.png}
\caption{Disclosure's Effect on the Privacy of the User’s Trajectory}%
{{}}
\label{fig:loss_quantification}
\end{subfigure}
\hfill
\caption{Demonstrator's User Interfaces}
\end{figure}
To demonstrate the impact of applying Differential Privacy (DP) to the user's location, the app's UI displays both the real and obfuscated locations, as illustrated in Fig.~\ref{fig:locations} (disclosed location in green, real location on gray, and points of interest are in red). Additionally, for each interaction with the LBS server—where a new obfuscated location is disclosed—the UI visualizes the effect of this disclosure on the privacy of the user's trajectory, as shown in Fig.~\ref{fig:loss_quantification}.
This use case demonstrator shows that our framework effectively balances privacy and utility by leveraging Differential Privacy to protect users' location data while maintaining the functionality of location-based services. By visualizing both real and obfuscated locations, as well as the evolving privacy impact on the user's trajectory, our approach enhances user awareness and control over their data.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Discussion %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% max 2 pages %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Discussion}\label{sect:discussion}
In this section, we first introduce lessons learned through our project, then compare our project results to related work from the privacy engineering domain, and eventually discuss limitations and future work.
\subsection{Lessons learned}
%In this subsection, we highlight general lessons learned within the project during the development of our framework and from discussion sessions.
Initially, the integration within the \emph{automotive hardware} was very difficult as we wanted to target a board that was running a partly-proprietary Android-based framework. After switching to another board that supports an ARM build of Debian Linux, the development became significantly easier than expected. As we are now using an ARM Cortex-A53 quad-core CPU with 4GB RAM, we also have a rather high-end build compared to ordinary automotive hardware. Thus, we are rather at the (automotive) high performance computing (HPC) area and the application of PETs has proven to be significantly faster than anticipated, without appearing to create any bottlenecks. However, we had developed the architecture to perform computations whenever possible in a privacy-friendly environment outside of the vehicle.
%For the usecase of data processing on third-party servers, the processing on these servers is where the majority of computation takes place.
We noticed that there is a \emph{lack of standardization for PETs}. Especially, when it comes to adding noise to mask raw values, there was no easy way to refer to specific noise levels (e.\,g.\ low/medium/high).
The automotive domain might stand out from other domains as \emph{location data} seems to be by far the most important data type, and in contrast to mobile phones, the user/driver can often not easily disable them.
With connected autonomous vehicles being promised within the next years, there might be a focus shift from \emph{behavioural driving data} towards \emph{support data for autonomous driving} as driving characteristics can no longer be easily fingerprinted in autonomous vehicles.
The diverse set of the studied scenarios has clearly demonstrated the challenges in selecting appropriate cryptographic PETs for specific contexts. For instance, in the real-time platooning scenario, the computational overhead associated with acceleration command encryption posed a significant challenge to maintaining platoon stability. As a result, it became necessary to couple Order-Preserving Encryption with HE to facilitate the computation of vehicle ordering within the platoon~\cite{chah2023h3pc}. However, exposing the order of vehicles introduces a trade-off, as it partially reveals position information to external parties. This trade-off highlights the complexity of balancing privacy preservation and system performance in real-time applications.
In other words, the \emph{practical deployment of PETs is not always seamless} and often requires substantial adaptation efforts to align with real-world constraints. This issue also raises broader concerns regarding methodological gaps and the lack of standardization in the field of privacy-preserving applications~\cite{BATRA2025100164}. One approach to address these challenges is to propose a privacy-preserving architecture for automotive applications. Such an architecture would serve as a foundation for discussion, enabling continuous improvement based on state-of-the-art research, real-world use cases, and feedback from stakeholders involved in the service ecosystem. Another advantage of such an architecture is the standardization of protocols and PET implementations in the automotive industry.
While certain challenges may be mitigated using existing standards, their effectiveness depends on two key factors:
\begin{itemize}
\item A comprehensive integration within privacy-preserving applications to ensure their relevance in real-world scenarios.
\item The extension of existing standards with new functionalities that address emerging privacy challenges and technological advancements.
\end{itemize}
This structured approach aims to bridge the gap between theoretical privacy mechanisms and practical implementation constraints, fostering the development of scalable, efficient, and privacy-compliant services.
\subsection{Comparison of Project Results to Related Work}
In this subsection, we discuss how our findings relate to general findings of privacy engineering papers. We contribute to results with more \emph{practical applicability in real-world information systems}~\cite{pallas2024privacy} by focusing on the automotive domain and in particular, investigating the four specific use-cases and developing tailored PETs, the automotive privacy framework along with a demonstrator for location-based services \emph{in a realistic setting}~\cite{pallas2024privacy}. \citet{gurses2011engineering} and \citet{spiekermann2012challenges} state that engineers find it hard to \emph{translate from abstract, ambiguous privacy requirements to specific technologies and solutions}. While this is in general a hard problem, which has already been partially addressed~\cite{lobner2021comparison,rannenberg2021study}, we could contribute to a subset of the challenge by mapping privacy principles of the GDPR~\cite{gdpr} to PETs. The mapping supports privacy engineers by excluding non suitable PETs. The provided assessment of the PETs maturity towards different dimensions then further supports the selection process. However, even though we ease the \emph{PET selection process}, still some specialized expertise will be required~\cite{notario2015pripare}.
Many approaches focus on the principle of data minimization~\cite{gurses2015engineering}. With our proposal to technically enforce purpose limitation, we are \emph{going beyond anonymization, data minimization and
security}~\cite{pallas2024privacy} and demonstrate that it is possible to address purpose limitation not only by consent and legal work. \citet{kostova2020privacy} highlights the \emph{challenges of dealing with services}. Our automotive privacy framework specifically considers different services from different providers: By bundling outgoing data, we assure that no more data than needed is send to the data lake in the cloud where the data is distributed among the different services. One reason for the architecture decision was also to \emph{reduce performance overheads}~\cite{pallas2024privacy} for applying PETs and the used traffic from vehicles to the cloud backend.
Our framework also supports the \emph{composition of different PETs}~\cite{kostova2020privacy}. In particular, we are applying ABE on top of all other PETs to enforce purpose limitation, and thus also \emph{minimize trust assumptions}~\cite{kostova2020privacy}.
Last but not least, we provide \emph{technical artifacts that are easily reusable in real-world environments}~\cite{pallas2024privacy}: a source code\footnote{\url{https://github.com/badr007-01/Building-a-Database-of-Simulated-Driver-Behaviors-Using-the-SUMO-Simulator}} that runs the SUMO simulator and generates a dataset of three different driver behaviors (Slow, Normal, Dangerous). We use this dataset to initially construct the ML model for the UBI use case. Additionally, we provide a library\footnote{\url{https://github.com/badr007-01/Usage_Based_insurance_DP_HE_from_SUMODataset}} that offers a decentralized ML algorithm combining DP and HE to protect sensitive data .
\subsection{Limitations}
Our technical enforcement of purpose limitation suffers from the limitation that when using ABE, the access to certain data can only be limited to a certain party. If the party is not at least semi-honest, it could use the data for other purposes. To prevent it, sophisticated watermarking or digital right management systems would be needed. However, since our proposal is an improvement of the status quo, we refer to \citet{pallas2024privacy} and relax on so far predominant “all-or-nothing” aspirations.
Additionally, we observed that revocation challenges have not been tackled in our solution yet. Once the personal data is available to a service provider or stored in the data lake, it is challenging~-- if not impossible~-- to revoke already distributed data.
Furthermore, the introduction of a trusted third-party that issues all the keys for \textit{ABE}, makes it effectively becoming the GDPR data controller, meaning that the liability for ensuring correct access control might be also passed to that party. This could introduce regulatory burdens and legal risks.
As a central element of our work is the application of PETs to ensure data privacy and the design of a future-proof Automotive data architecture, it is necessary to point out that many \textit{PETs} are not safe against sophisticated quantum-computers as many \textit{PETs} are based on traditional asymmetric schemes such as RSA or ECC. However, \textit{PETs} such as Zero-Knowledge-Proofs based on hash-based signatures or lattice-based FHE remain secure.
Regarding the PET selection, we did not introduce a measure to evaluate the impact of applying the different possible PETs or their combinations~\cite{ABMPPB24iwpe}. Thus, it is also not clear how close the finally selected solution would be to the optimal solution -- only using the minimal amount of data needed to provide the specific service.
\subsection{Future work}
We support the statements by \citet{kostova2020privacy} that standardization is one of the major challenges. This holds not only for PETs themselves, but also for instantiating / configuring / parameterizing them. Although we proposed a way to coordinate the application of PETs within the vehicle by the privacy manager (PM), the information exchange between the PM and applications needs at least a de facto standard, perhaps similar to the way apps in Android are configured.
Similar privacy frameworks like ours are needed for other domains as well. This would allow us to answer the question if there are possibilities to generalize the results beyond single domains, such as in our case the automotive domain.
Our work was mostly focused on the privacy architects' and developers' perspective. It would also be interesting to consider the user's perspective, that is, the user acceptance effects and criteria for PETs as already done for machine learning~\cite{LPB23trustbus,LPBP24arxiv}. User perceptions of PETs considering technology use behavior~\cite{HPR20pets} willingness to pay~\cite{HCP19ifipsec}, privacy concerns~\cite{HP18ifipsec}, risk beliefs~\cite{HP19hicss}, privacy literacy~\cite{HP20sigmis}, and perceived anonymity and trust~\cite{HP18amcis} have been investigated in the past by Harborth et al.\ and shown to have a huge influence on the acceptance of PETs by endusers. Therefore, it would be a another challenge to include those into the architecture design and PET selection process, perhaps along with other economic criteria such as licenses of the PETS, fees and operating costs, and availability of knowledgeable experts.
\section{Conclusion}\label{sect:conclusion}
With the AUTOPSY project, we could contribute to the privacy world for automotive with a couple of ideas, such as a system model, the privacy manager, a PET selection process based on GDPR principles, the development of tailored PETs, and the privacy framework resulting in a demonstrator for the location-based service use case.
Given the particular challenges of supply chains in the automotive domain, it will be particular interesting to see if and which of the ideas can make it to real products. Most likely, it will also depend on the efforts and willingness of all players to contribute to standardization of the used PETs, their configuration and the needed interfaces.
\section*{Acknowledgements}
The authors would like to thank Armando Miguel Garcia and Mario Hoffmann for their contributions to the project. This work was suported by the Federal Ministry of Education and Research, Germany (BMBF) under grant number 16KIS1382 and by the Agence Nationale de la Recherche, France (ANR) under grant number ANR-20-CYAL-0008.
%%
%% The next two lines define the bibliography style to be used, and
%% the bibliography file.
%\begingroup %Avoid pagebreak before References
%\let\clearpage\relax
%\vspace{4mm}
\bibliographystyle{splncs04nat}
\bibliography{references}
All URLs have been last accessed on May 14th, 2025.
%\endgroup
\end{document}
\begin{thebibliography}{36}
\providecommand{\natexlab}[1]{#1}
\providecommand{\url}[1]{\texttt{#1}}
\providecommand{\urlprefix}{URL }
\expandafter\ifx\csname urlstyle\endcsname\relax
\providecommand{\doi}[1]{doi:\discretionary{}{}{}#1}\else
\providecommand{\doi}{doi:\discretionary{}{}{}\begingroup
\urlstyle{rm}\Url}\fi
\bibitem[{Al-Momani et~al.(2024)Al-Momani, Balenson, Mann, Pape, Petit, and
B{\"o}sch}]{ABMPPB24iwpe}
Al-Momani, A., Balenson, D., Mann, Z.{\'A}., Pape, S., Petit, J., B{\"o}sch,
C.: Navigating privacy patterns in the era of robotaxis. In: IEEE EuroS\&P
Workshops, IWPE, pp. 32--39 (07 2024), \doi{10.1109/EuroSPW61312.2024.00011}
\bibitem[{Balador et~al.(2022)Balador, Bazzi, Hernandez-Jayo, de~la Iglesia,
and Ahmadvand}]{platooning}
Balador, A., Bazzi, A., Hernandez-Jayo, U., de~la Iglesia, I., Ahmadvand, H.: A
survey on vehicular communication for cooperative truck platooning
application. Vehicular Communications (2022)
\bibitem[{Batra et~al.(2025)Batra, Goel, Reyes, Assoumou, Simangan, Abdulla,
and Kuhls}]{BATRA2025100164}
Batra, K., Goel, V.S., Reyes, A.L., Assoumou, B., Simangan, D.P., Abdulla, F.,
Kuhls, D.A.: Unifying and linking data sources in medical and public health
research. Journal of Medicine, Surgery, and Public Health \textbf{5}, 100164
(2025), \doi{https://doi.org/10.1016/j.glmedi.2024.100164}
\bibitem[{Bkakria and Yaich(2024)}]{bkakria2024framework}
Bkakria, A., Yaich, R.: A framework for managing multifaceted privacy leakage
while optimizing utility in continuous lbs interactions (2024)
\bibitem[{Chah et~al.(2025)Chah, Anis~Bkakri, Brunoud, Mualla, and
Yaich}]{UBI_25}
Chah, B., Anis~Bkakri, Alexandre~Lombard, a.A.T., Brunoud, A., Mualla, Y.,
Yaich, R.: Privfedprofiling: Privacy-preserving federated profiling model for
enhanced usage-based insurance assessment (2025)
\bibitem[{Chah et~al.(2023)Chah, Lombard, Bkakria, Abbas-Turki, and
Yaich}]{chah2023h3pc}
Chah, B., Lombard, A., Bkakria, A., Abbas-Turki, Yaich, R.: H3pc: Enhanced
security and privacy-preserving platoon construction based on fully
homomorphic encryption. In: IEEE ITSC (2023)
\bibitem[{Chah et~al.(2024)Chah, Lombard, Mualla, Bkakria, Abbas-Turki, and
Yaich}]{10.1007/978-3-031-66428-1_34}
Chah, B., Lombard, A., Mualla, Y., Bkakria, A., Abbas-Turki, A., Yaich, R.:
Building a database of simulated driver behaviors using the sumo simulator.
In: IntelliSys, pp. 536--555 (2024)
\bibitem[{of~the European~Union(2016)}]{gdpr}
of~the European~Union, C.: Regulation (eu) 2016/679 of the european parliament
and of the council of 27 april 2016 on the protection of natural persons with
regard to the processing of personal data and on the free movement of such
data, and repealing directive 95/46/ec (general data protection regulation).
Official Journal of the European Union vol. 59 (2016)
\bibitem[{Geoghegan et~al.(2025)Geoghegan, Patton, Pitman, Rescorla, and
Wood}]{ietf-ppm-dap-14}
Geoghegan, T., Patton, C., Pitman, B., Rescorla, E., Wood, C.A.: {Distributed
Aggregation Protocol for Privacy Preserving Measurement}. Tech. rep., {IETF}
(2025), work in Progress
\bibitem[{G{\"u}rses et~al.(2011)G{\"u}rses, Troncoso, and
Diaz}]{gurses2011engineering}
G{\"u}rses, S., Troncoso, C., Diaz, C.: Engineering privacy by design.
Computers, Privacy \& Data Protection \textbf{14}(3), 25 (2011)
\bibitem[{G{\"u}rses et~al.(2015)G{\"u}rses, Troncoso, and
Diaz}]{gurses2015engineering}
G{\"u}rses, S., Troncoso, C., Diaz, C.: Engineering privacy by design reloaded.
In: Amsterdam Privacy Conference, vol.~21 (2015)
\bibitem[{Harborth et~al.(2019)Harborth, Cai, and Pape}]{HCP19ifipsec}
Harborth, D., Cai, X., Pape, S.: Why do people pay for privacy-enhancing
technologies? the case of tor and jondonym? In: {IFIP} {SEC}, pp. 253--267
(06 2019), \doi{10.1007/978-3-030-22312-0_18}
\bibitem[{Harborth and Pape(2018{\natexlab{a}})}]{HP18amcis}
Harborth, D., Pape, S.: Examining technology use factors of privacy-enhancing
technologies: The role of perceived anonymity and trust. In: {AMCIS},
Association for Information Systems (2018{\natexlab{a}}),
\urlprefix\url{https://aisel.aisnet.org/amcis2018/Security/Presentations/15}
\bibitem[{Harborth and Pape(2018{\natexlab{b}})}]{HP18ifipsec}
Harborth, D., Pape, S.: Jondonym users' information privacy concerns. In:
{IFIP} {SEC}, pp. 170--184 (08 2018{\natexlab{b}}),
\doi{10.1007/978-3-319-99828-2_13}
\bibitem[{Harborth and Pape(2019)}]{HP19hicss}
Harborth, D., Pape, S.: How privacy concerns and trust and risk beliefs
influence users' intentions to use privacy-enhancing technologies -- the case
of tor. In: {HICSS}, pp. 4851--4860 (01 2019), \doi{10125/59923}
\bibitem[{Harborth and Pape(2020)}]{HP20sigmis}
Harborth, D., Pape, S.: How privacy concerns, trust and risk beliefs and
privacy literacy influence users' intentions to use privacy-enhancing
technologies - the case of tor. ACM SIGMIS Database (2020),
\doi{10.1145/3380799.3380805}
\bibitem[{Harborth et~al.(2020)Harborth, Pape, and Rannenberg}]{HPR20pets}
Harborth, D., Pape, S., Rannenberg, K.: Explaining the technology use behavior
of privacy-enhancing technologies: The case of tor and jondonym. Proceedings
on PoPETs (2020), \doi{10.2478/popets-2020-0020}
\bibitem[{Jin et~al.(2021)Jin, Chen, Hsu, Yu, and Chen}]{NEURIPS2021_08040837}
Jin, X., Chen, P.Y., Hsu, C.Y., Yu, C.M., Chen, T.: Cafe: Catastrophic data
leakage in vertical federated learning. In: NeurIPS (2021)
\bibitem[{Kostova et~al.(2020)Kostova, G{\"u}rses, and
Troncoso}]{kostova2020privacy}
Kostova, B., G{\"u}rses, S., Troncoso, C.: Privacy engineering meets software
engineering. on the challenges of engineering privacy bydesign.
arXiv:2007.08613 (2020)
\bibitem[{L\"obner et~al.(2023)L\"obner, Pape, and Bracamonte}]{LPB23trustbus}
L\"obner, S., Pape, S., Bracamonte, V.: User acceptance criteria for privacy
preserving machine learning techniques. In: {ACM ARES} (2023),
\doi{https://doi.org/10.1145/3600160.3605004}
\bibitem[{L{\"o}bner et~al.(2024)L{\"o}bner, Pape, Bracamonte, and
Phalakarn}]{LPBP24arxiv}
L{\"o}bner, S., Pape, S., Bracamonte, V., Phalakarn, K.: Which {PPML} would a
user choose? a structured decision support framework for developers to rank
{PPML} techniques based on user acceptance criteria (2024),
\doi{10.48550/arXiv.2411.06995}
\bibitem[{L{\"o}bner et~al.(2021)L{\"o}bner, Tronnier, Pape, and
Rannenberg}]{lobner2021comparison}
L{\"o}bner, S., Tronnier, F., Pape, S., Rannenberg, K.: Comparison of
de-identification techniques for privacy preserving data analysis in
vehicular data sharing. In: ACM CSCS, pp. 1--11 (2021)
\bibitem[{McMahan et~al.(2017)McMahan, Moore, Ramage, Hampson, and
y~Arcas}]{mcmahan2017communication}
McMahan, H.B., Moore, E., Ramage, D., Hampson, S., y~Arcas, B.A.:
Communication-efficient learning of deep networks from decentralized data.
In: AISTATS, pp. 1273--1282 (2017),
\urlprefix\url{http://proceedings.mlr.press/v54/mcmahan17a.html}
\bibitem[{Notario et~al.(2015)Notario, Crespo, Mart{\'\i}n, Del~Alamo,
Le~M{\'e}tayer, Antignac, Kung, Kroener, and Wright}]{notario2015pripare}
Notario, N., Crespo, A., Mart{\'\i}n, Y.S., Del~Alamo, J.M., Le~M{\'e}tayer,
D., Antignac, T., Kung, A., Kroener, I., Wright, D.: Pripare: integrating
privacy best practices into a privacy engineering methodology. In: IEEE SPW
(2015)
\bibitem[{Pallas et~al.(2024)Pallas, Koerner, Barber{\'{a}}, Hoepman, Jensen,
Narla, Samarin, Ulbricht, Wagner, Wuyts, and Zimmermann}]{pallas2024privacy}
Pallas, F., Koerner, K., Barber{\'{a}}, I., Hoepman, J., Jensen, M., Narla,
N.R., Samarin, N., Ulbricht, M., Wagner, I., Wuyts, K., Zimmermann, C.:
Privacy engineering from principles to practice: A roadmap. IEEE Security \&
Privacy \textbf{22}(2), 86--92 (2024)
\bibitem[{Pape et~al.(2025)Pape, Bkakria, Chah, Heymann, and
Winkler}]{PBCHS25ares}
Pape, S., Bkakria, A., Chah, B., Heymann, M., Winkler, S.S.: A framework for
supporting pet selection based on gdpr principles. In: Proceedings of the
20th International Conference on Availability, Reliability and Security,
{ARES} 2025, Ghent, Belgium, 11 August 2025 - 14 August 2025 (08 2025), to
appear
\bibitem[{Pape et~al.(2023)Pape, Syed-Winkler, Garcia, Chah, Bkakria, Hiller,
Walcher, Lombard, Abbas-Turki, and Yaich}]{PSGCBHWLAY23cscs}
Pape, S., Syed-Winkler, S., Garcia, A.M., Chah, B., Bkakria, A., Hiller, M.,
Walcher, T., Lombard, A., Abbas-Turki, A., Yaich, R.: A systematic approach
for automotive privacy management. In: {CSCS}, ACM (12 2023),
\doi{10.1145/3631204.3631863}
\bibitem[{Paul et~al.(2018)Paul, Tesfay, Kipker, Stelter, and
Pape}]{PTKSP18ifipsec}
Paul, N., Tesfay, W.B., Kipker, D.K., Stelter, M., Pape, S.: Assessing privacy
policies of internet of things services. In: {IFIP} {SEC}, pp. 156--169 (08
2018), \doi{10.1007/978-3-319-99828-2\_12}
\bibitem[{Rannenberg et~al.(2021)Rannenberg, Pape, Tronnier, and
L{\"o}bner}]{rannenberg2021study}
Rannenberg, K., Pape, S., Tronnier, F., L{\"o}bner, S.: Study on the technical
evaluation of de-identification procedures for personal data in the
automotive sector. Tech. rep. (2021)
\bibitem[{Ren et~al.(2022)Ren, Deng, and Xie}]{10.1145/3510032}
Ren, H., Deng, J., Xie, X.: Grnn: Generative regression neural network—a data
leakage attack for federated learning. ACM TIST \textbf{13}(4) (2022), ISSN
2157-6904, \doi{10.1145/3510032}
\bibitem[{Spiekermann(2012)}]{spiekermann2012challenges}
Spiekermann, S.: The challenges of privacy by design. Communications of the ACM
\textbf{55}(7), 38--40 (2012)
\bibitem[{Syed-Winkler et~al.(2022)Syed-Winkler, Pape, and Sabouri}]{SPS22cscs}
Syed-Winkler, S., Pape, S., Sabouri, A.: A data protection-oriented system
model enforcing purpose limitation for connected mobility. In: {CSCS}, ACM
(12 2022), \doi{10.1145/3568160.3570231}
\bibitem[{Tronnier et~al.(2022)Tronnier, Pape, L{\"o}bner, and
Rannenberg}]{tronnier2022discussion}
Tronnier, F., Pape, S., L{\"o}bner, S., Rannenberg, K.: A discussion on ethical
cybersecurity issues in digital service chains. In: Cybersecurity of Digital
Service Chains: Challenges, Methodologies, and Tools (2022)
\bibitem[{Wang(2021)}]{wangsilent}
Wang, C.: Silent Testing for Safety Validation of Automated Driving in Field
Operation. Ph.D. thesis (2021)
\bibitem[{Wei et~al.(2021)Wei, Liu, Wu, Su, and Iyengar}]{9546481}
Wei, W., Liu, L., Wu, Y., Su, G., Iyengar, A.: Gradient-leakage resilient
federated learning. In: ICDCS, pp. 797--807 (2021),
\doi{10.1109/ICDCS51616.2021.00081}
\bibitem[{Yang et~al.(2024)Yang, Guo, Zhu, Tjuawinata, Zhao, and
Lam}]{yang2024local}
Yang, M., Guo, T., Zhu, T., Tjuawinata, I., Zhao, J., Lam, K.Y.: Local
differential privacy and its applications: A comprehensive survey. Computer
Standards \& Interfaces \textbf{89}, 103827 (2024)
\end{thebibliography}