Sebastian Pape
email: sebastian.pape@continental.com

Sarah Syed-Winkler
email: sarah.syed-winkler@continental.com

Armando Miguel Garcia
email: armando.miguel.garcia@aisec.fraunhofer.de

Abdeljalil Abbas-Turki
email: abdeljalil.abbas-turki@utbm.fr

Badreddine Chah
email: badreddine.chah@utbm.fr

Anis Bkakria
email: anis.bkakria@irt-systemx.fr

Matthias Hiller
email: matthias.hiller@aisec.fraunhofer.de

Tobias Walcher
email: tobias.walcher@continental.com

Alexandre Lombard
email: alexandre.lombard@utbm.fr

Reda Yaich
email: reda.yaich@irt-systemx.fr

A Systematic Approach for Automotive Privacy Management

Keywords: automotive, privacy, system model, data protection, platooning, silent testing

As of today, car manufacturers are currently addressing privacy goals primarily from a legal perspective. However, with the common acceptance of privacy by design, it is important to also address the technical perspective. As of today there is no systematic understanding or even approach how to address privacy requirements. Our contribution is twofold: (i) We propose a system model for the automotive domain to model and analyse a use case for suitable locations of adding privacy enhancing technologies. (ii) As a generic solution, we propose the privacy manager, a generic entity which supports applications in the implementation of privacy enhancing technologies or enforces a certain data flow avoiding that information is leaked in an avoidable way. To evaluate our approach, we apply our system model at two automotive scenarios, platooning and silent testing, and describe how the privacy manager can be used to integrate privacy considerations early on. In general our proposed system model was easily applicable to the two chosen use cases.

INTRODUCTION

Rapidly changing digital technologies such as the Internet of Things (IoT), cloud technologies and Artificial Intelligence (AI) are challenging traditional industries such as automotive, which have longer innovation and development cycles. The current trends of connecting vehicles with local infrastructures and cloud backends [START_REF] Neumann | Seven Automotive Connectivity Trends Fueling the Future[END_REF] and changing to software defined vehicles [START_REF] Halba | In-vehicle software defined networking: An enabler for data interoperability[END_REF] promise to start a new area of intelligent transport systems and autonomous vehicles with great potential for data-driven applications, improved user experiences, and new business models. Vehicles are becoming a connected system of multiple computers. Despite all the benefits, this changes are a huge challenge to building secure and privacy friendly systems for the automotive industry. Addressing these issues is not just a matter of compliance to automotive homologation, a multitude of automotive specific (cybersecurity) regulations [START_REF] Schober | Cybersecurity Regulations and Standards in the Automotive Domain[END_REF] 1 and to non automotive specific (privacy) regulations such as the General Data Protection Regulation (GDPR) [38], but also a crucial matter for user acceptance and adoption of the new system. As in many other areas [6, 24-27, 29, 39], privacy concerns play a crucial role in adoption. [START_REF] Cai | Understand Users' Privacy Perception and Decision of {V2X} Communication in Connected Autonomous Vehicles[END_REF] found that users weight benefits against privacy and security risks. Non surprisingly, one of their findings was that users perceive larger benefits in automotive use cases for driving-related scenarios compared to infotainment scenarios.

As of today, car manufacturers are currently addressing privacy goals such as transparency, purpose limitation, or right to be forgotten primarily from a legal perspective. The technical implications, on the other hand, have not yet been adequately evaluated. However, their influence is broad and diverse: from the compliant handling of the Vehicle Identification Number (VIN) to the management of movement profiles over time, there is no common technical understanding or solution in the automotive community on how to adequately address those topics. Guaranteeing privacy-friendly data handling must be a minimum standard even when users are consenting to use data-driven applications. The use of mobility services should not imply that users have to give up their privacy in exchange. Data protection must be incorporated into the system design in an early design phase and technical measures need to ensure data protection goals in a verifiable way.

The contribution of our paper is twofold:

(i) We present a system model which allows modeling automotive use cases to investigate the relevant level of abstraction, communication and trust model and the used data as a basis for eliciting privacy requirements. (ii) We present the privacy manager, a generic entity which provides different operations modes to support applications on the vehicle by offering a coordinated mechanism to apply privacy enhancing technologies or to enforce a certain data flow.

To evaluate our approach, we apply our system model at two automotive scenarios, platooning and silent testing, and describe how the privacy manager can be used to integrate privacy considerations early on.

The remainder is structured as follows: Sect. 2 provides an overview of related work. Sect. 3 outlines our methodology. Sect. 4 describes the developed system model and Sect. 5 defines our solution for the automotive privacy architecture. The evaluation is presented in Sect. 6, Sect. 7 discusses our results and limitations and Sect. 8 concludes the paper.

RELATED WORK

We investigated three areas for related work: Automotive system models, automotive privacy engineering, and privacy threat elicitation in the automotive domain:

Automotive System Models. Boettner et al. [START_REF] Boettner | Proton exchange membrane fuel cell system model for automotive vehicle simulation and control[END_REF] describe a system model for automotive applications with a focus on fuel cells. Due to the completely different context, we do not go into details here. Syed-Winkler et al. [START_REF] Syed-Winkler | A Data Protection-Oriented System Model Enforcing Purpose Limitation for Connected Mobility[END_REF] proposes a system model in the automotive privacy domain. However, their model has the aim to enforce purpose limitation, whereas our approach extends the model to also consider other privacy principles. Furthermore, our privacy manager has been further developed and generalized to be applicable across various scenarios. Al-Momani et al. [START_REF] Ala | iRide: A Privacy-Preserving Architecture for Self-Driving Cabs Service[END_REF] provide a privacypreserving architecture for self-driving cab services which models only one specific scenario whereas we propose a more generic system model and architecture which should be applicable in the majority of use cases.

Automotive Privacy Engineering. The autonomous vehicle represents a transformative technological advancement poised to revolutionize our travel habits and usher in innovative mobility services. Rooted in Artificial Intelligence and Connectivity, it involves complex decision-making processes and a multitude of data exchanges related to both passengers inside the vehicle and external road users. The work conducted by [START_REF] Krontiris | Autonomous Vehicles: Data Protection and Ethical Considerations[END_REF] serves as a crucial reminder of the ethical and privacy challenges inherent to this technological advancement. It identifies gaps in existing research work and provides a series of insightful recommendations. Meanwhile, [START_REF] Frank | Privacy by Design: Survey on Capacitive Proximity Sensing as System of Choice for Driver Vehicle Interfaces[END_REF] and [START_REF] Cai | Understand Users' Privacy Perception and Decision of {V2X} Communication in Connected Autonomous Vehicles[END_REF] delve deep into these concerns by investigating various aspects from the users' perspective. In the first study, which scrutinizes the driving attention system from the more than two hundred participants' standpoint, privacy-related apprehensions emerge as an issue. Participants express reservations regarding the use of cameras and prefer capacitive proximity sensing sensors instead, reflecting their privacy concerns. The second study, involving over six hundred participants, focuses on connected ITS (Intelligent Transportation Systems) services. It uncovers similar privacy worries associated with these services while highlighting the attraction of their benefits. As a result, the authors propose recommendations targeting both manufacturers and legislators to address privacy concerns effectively. Recently, several studies proposed privacyfriendly protocols tailored to specific services within vehicles. These protocols aim to ensure the privacy and security of users in services like autonomous cabs [START_REF] Ala | iRide: A Privacy-Preserving Architecture for Self-Driving Cabs Service[END_REF], ride-sharing [START_REF] Ramezanian | Lightweight Privacy-Preserving Ride-Sharing Protocols for Autonomous Cars[END_REF], and platooning [START_REF] Zimmermann | Attribute-Based Credentials in High-Density Platooning[END_REF], harnessing Intel SGX, attribute-based credentials and modified tree DH group key exchange protocol with homomorphic encryption, respectively. However, the multiplicity of potential services, the extent to which these services can be customized, the various possible access points inside and outside the vehicle, and the complexity of the vehicle's architecture, with its numerous components and data exchanges and processing, call for in-depth privacy by design engineering framework. Other work in the area of privacy engineering adresses the question how to chose a suitable privacy enhancing technology for a given problem [START_REF] Löbner | Comparison of de-identification techniques for privacy preserving data analysis in vehicular data sharing[END_REF] and provide a prototype implementation of one of the identified variants in their follow-up work [START_REF] Löbner | Privacy Preserving Data Analysis with the Encode, Shuffle, Analyse Architecture in Vehicular Data Sharing[END_REF].

Privacy threat elicitation. In the context of the Privacy Engineering framework, privacy threat analysis is considered a crucial step that should be initiated from the outset to attain a comprehensive understanding of the systems involved. Numerous methodologies have been documented in the literature, including the Privacy Impact Assessment (PIA), alternatively referred to as privacy risk assessment, as well as the LINDDUN methodology. These two techniques share a kind of similar procedural approach. LINDDUN [START_REF] Wuyts | Linddun go: A lightweight approach to privacy threat modeling[END_REF] is an acronym that delineates the various categories of threats in privacy analysis. These threats can be classified into two main groups: hard privacy threats, encompassing Linkability, Identifiability, Nonrepudiation, Detectability, and Disclosure of information, and soft privacy threats, including Unawareness and Non-compliance. In the paper [START_REF] Chah | Privacy Threat Analysis for connected and autonomous vehicles[END_REF], the authors present a comprehensive privacy threat analysis of the general architecture of connected and autonomous vehicles (CAVs) aimed at identifying privacy risks in accordance with formal privacy requirements. Furthermore, the authors offer an up-to-date overview of recent privacy attack scenarios concerning CAVs. Additionally, they provide a use case classification and analysis, aiding in the identification of privacy requirements that can be implemented by manufacturers. To achieve these objectives, they employ the LINDDUN methodology for privacy threat analysis. An extension of this work has been published [START_REF] Chah | Privacy, Security, Threat Analysis, Connected and Autonomous Vehicle, Privacy engineering framework[END_REF], focusing on a specific use case to assist manufacturers in implementing privacy requirements and enhancing privacy protection. Other recent work on threat elicitation combines asset-oriented ISO approach with the threat-oriented STRIDE approach tailored to the level of specific car brand [START_REF] Bella | A double assessment of privacy risks aboard top-selling cars[END_REF] and highlights the need to extend the ENISA's privacy threats [START_REF] Raciti | How to Model Privacy Threats in the Automotive Domain[END_REF].

METHODOLOGY

The system model was built in multiple iterations based on several discussions within the consortium of the AUTOPSY project 2 . In a first step, the problem was analyzed and modelled with legal support to create a privacy-centric system representing the data flows.Representative sample cases were discussed with the aim to allow a solution capable of modeling On-Board (OnB), Off-Board (OfB), and On-the-Cloud (OtC) components and their interaction.

For the evaluation of the proposed model, we chose two different scenarios: platooning and silent testing (as described in Sect. 6). Scenarios were chosen on the available in-depth knowledge by the authors and their working groups and to represent two scenarios with different goals and entities.

SYSTEM MODEL

In this section, we first describe the involved entities (see Sect. 4.1) as shown in Fig. 1. The figure also shows the different levels of the core system model (see Sect. 4.2). The next subsections consider the In-Vehicle-Architecture in more detail (see Sect. 4.3) and then present our communication (see Sect. 4.4) and trust models (see Sect. 4.5). Last, we discuss considerations on the data classification (see Sect. 4.6).

Entities

For a better understanding of the proposed system model, we describe the involved entity types briefly. Depending on the scenario, multiple instances of the same entity may occur.

Vehicle Generally, the in-vehicle architecture encompasses several entities, including Electronic Control Units (ECUs), sensors, actuators, zone controllers, High-Performance Computers (HPCs), among others. Device A device refers to the connection of any wired or wireless device with the vehicle, such as mobile phones or wireless keys. Roaduser Road users encompass additional vehicles or pedestrians actively participating in the immediate traffic environment. Service Provider Services can include fog or edge nodes, cloud backends, and third-party service providers.

Core Model

In this section, we define the core of the system model. The model consists of two different levels: system level and vehicle-2-x level. Across the levels, the connectivity is increasing, starting from a single ECU via the whole vehicle at the system level up to a broader scale of communication of the vehicle with other devices of the user (e. g., a mobile phone or the wireless keys), other road users, and the service infrastructure such as edge or cloud nodes of service providers. The In-Vehicle-Architecture will be further refined in distinguishing between a functional and a physical view on the topology of the used ECUs. On Vehicle-2-X level, the scope can be either to communicate with devices of the driver and passengers of the vehicle, other road users, where there is in general no contractual agreement made, or with a service provider with a corresponding agreement or service booking. One of the main differences between other road users and services is that the privacy of other road users needs to be respected -whereas service providers usually do not require to be protected. The exact definitions of each level are presented in Table 1.

In Figure 1 the different entities (orange text) and the different levels of the system model (grey text) are depicted in one picture. Two vehicles are shown consisting of multiple internal components (i. e., ECUs, controllers, HPC) which are all connected (In-Vehicle-Architecture). Both vehicles can communicate with each other (Vehicle-2-Roaduser), with some external cloud (Vehicle-2-Service) or with wireless devices, such as keys or smartphones (Vehicle-2-Device).

Functional and Topological

In-Vehicle-Architecture

The In-Vehicle-Architecture can be further refined to represent different aspects of the system: Functional and topological architecture views. The functional architecture groups different system functions such as motion, connectivity or perception and highlights the interaction of these different function groups, as shown exemplarily in Fig. 2. The topological architecture in Fig. 3 shows the topology of the vehicle and the corresponding functions of its components. Adding the physical interconnects reveals the different functionalities sitting on one bus, which is important to understand the actual data that is transmitted within the vehicle. Introducing a zonal architecture as in Fig. 3 with gateways and firewalls separates periphery and high-performance computers.

While the functional architecture helps to understand the functional interactions within the vehicle, it is critical for the security On ECU or HPC-level, we are looking at a single ECU which is deriving data from directly connected sensors and actuators. We treat an HPC equal to an ECU but with higher computation power. On this level, data is not leaving the ECU, not to mention the vehicle.

System

In-Vehicle-Architecture

The in-vehicle architecture consists of a multitude of ECUs, Sensors, Actuators, Zone Controllers, HPCs, etc. When analysing on in-vehicle-architecture level, it is assumed that data is transferred amongst the different components inside the vehicle, but data is not leaving the vehicle itself.

Vehicle-2-Device

Vehicle-2-Device refers to the (wireless) connection of any device with the vehicle. We assume the device is affiliated with the owner/driver/passenger of the car. Examples are mobile phones and wireless keys.

Vehicle-2-Roaduser

Vehicle-2-Roaduser refers to the data exchange with other road users, i.e., other vehicles, but also pedestrians. In this case, data leaves the vehicle to other road users. Road users have no direct agreement / contracts between them but might have one with the OEM or a service provider. Privacy of other road users needs to be respected.

Vehicle-2-X Vehicle-2-Service

Vehicle-2-Service is the broadest scale, where vehicles are communicating with fog or edge nodes, cloud backends and third parties. In this case, data leaves the vehicle to a (commercial) provider. The owner of the car might have an agreement / contract with the service provider. Services as commercial entities do not need to have their privacy protected.

and privacy assessment to also show the logical data exchange and bus systems as well.

Communication Model

Depending on the source and destination of data transmission, the communication model can be further specified and associated to the aforementioned system model levels. This association is presented in Table 2.

Trust model

When dealing with privacy and data protection issues, we need to take into consideration the trust relation between the data owner and the entity that is going to process and use the data. Focusing on the previous relation, three main adversary model are considered in the literature.

Untrusted party

The data owner/provider does not trust the considered entity that will be responsible for processing/using the data to be outsourced. As a consequence, whenever possible privacy requirements should be technically enforced. Semi-trusted party The data owner considers the party that is going to process/use the data as an honest-but-curious entity.

It is honest as it is supposed not to deviate from the defined protocol but may attempt to learn as much information as possible about the data owner out of the outsourced data. Trusted party The data owner/provider trusts the entity which will be charged of enabling the processing of their data while protecting their private/sensitive data. For example, because Data which is transmitted outside of the vehicle. This may be the result of certain services which require the transmission of data, e.g., crash notification and diagnostics systems, which share vehicle information for enabling services such as emergency calls and predictive maintenance. In the following, provide some examples for trust models in the proposed system.

OUT-IN

• Privacy Management Service: This service is considered a trusted entity as it is responsible for correctly enforcing the specified privacy policy on data and information that can be accessed and shared outside the vehicle. • Trusted Equipment: These entities, such as sensors and Electronic Control Units (ECUs), are expected to be trustworthy in processing data accurately and refrain from disclosing it to unauthorized third parties. • Third Party Services: These entities are classified as semitrusted because they are expected to perform their proposed functionalities correctly. However, there is a possibility that they may attempt to infer sensitive private information about vehicle users and share it with external parties. • Road Users: Road users are deemed potentially malicious or untrusted since they may try to deviate from the correct protocol, such as sending misleading information to the target vehicle.

Data Classification

The data collected by connected and autonomous vehicles (CAV) has been standardized and listed in detail [START_REF]Intelligent Transport Systems (ITS), Vehicular Communications, Basic Set of Applications[END_REF]. Thus, By analyzing the information [START_REF]Intelligent Transport Systems (ITS), Vehicular Communications, Basic Set of Applications[END_REF]36], we can deduce that personnel data within the realm of CAVs can be categorized into two distinct groups: one that provides direct access to the person's identity, and another that allows indirect access to the person's identity.

Direct identification:

The term refers to situations where the entity accessing the data might have the capability to identify specific individuals or vehicles associated with the data, potentially leading to privacy breaches. As an example, we can identify the ensuing private data elements including in this group:

• Users recognition: Many services are offered in today's cars to make life easier for users. This pushes the manufacturers to integrate more and more sensors into the vehicles. These sensors provide personally identifiable information such as fingerprints, faces, eye movements, and seat configurations. A malicious entity can guess some private information like the number of passengers and their identities.

PRIVACY MANAGEMENT FOR VEHICLE-2-X

For this section, we rely on a generic use case to describe the functionality of the privacy manager. We will apply the system model and describe how the privacy manager can be facilitated in more specific scenarios in Sect. 6.

The user is operating a car which has access to some (external) service running or exchanging information outside the vehicle (e. g., in the cloud). The interaction of the user with the vehicle is realized by a Human Machine Interface (HMI). The HMI allows the user to activate or deactivate automotive services and to permit or decline access from the services to his personal data. If the user changes settings, a trusted entity inside the vehicle called the privacy manager (PM) is responsible for implementing them by managing the privacy settings and applying and monitoring data protection measures. The PM is also responsible for reacting to changes in the privacy settings and adapting appropriate PETs to meet pre-defined data protection requirements. This is also beneficial for a holistic concept of privacy in the vehicle since the PM can act as a single point which can consider different privacy settings without the need of each application to be able to react to it. While the PM can also be applied for data flows inside the vehicle, data not leaving the vehicle tends to be a smaller problem. Thus, the main objective of the PM is to protect personal or sensitive data for Vehicle-2-X communication. With protection, we are referring to being compliant with the GDPR principles for processing personal data with the help of selective Privacy-Enhancing Technologies. The proposed system model from the previous section represents our system-in-scope in a generic way, the PM provides a coordinated mechanism to apply PETs. The PM offers an interface to PETs so that it is not required for each application to employ additional privacy measures individually. This not only allows to harmonize the implementation of such PETs, e. g., with regards to which algorithms are being used, but also allows a more efficient key management, as any PET relying on encryption can be employed by the applications without the need to fully configure it.

Fig. 4 depicts an abstracted view of the vehicles architecture. We assume that the PM and potential applications are running in an high-performance computing platform (HPC). However, applications could also be accessing the PM from a standalone ECU. A gateway connects the HPC with the communication bus which offers access to sensors and actuators, on board diagnostics and an infotainment component. The PM has access to certain libraries which serve two purposes: Application of PETs and computation on raw data as sketched below.

There are four different modes in the vehicle for operating with the PM, which are listed below with respective examples. In the first operation mode called "Direct Access", the communication is taking place with a trusted party. For the remaining operations, we assume a semi-trusted or untrusted party and therefore intend to limit their access to raw data and/or to transfer data outside of the vehicle.

Direct Access

The application has direct access to the required data and does not interact with the PM at all. This is the case when no sensitive data is communicated or communication is happening with a trusted party (i.e., OEM) PET application The application communicates with the PM over an API to apply PETs on the required data. Libraries may implement PETs which the PM then can offer to applications, e. g. various forms of encryption (homomorphic, attributebased, etc.), multi-party computation or approaches to add noise to the data, e. g. to fulfil differential privacy. This can apply to services like a location or navigation service (IN-OUT), where e. g., access to certain sensitive data is limited to legitimate parties. Computation from raw data The application requests data from the PM, which only delivers the result of a computation and not the raw data itself. The libraries may be provided by the applications with the aim that the application itself will not get access to the raw data of the sensors but only to the result of the computation.

EVALUATION

To evaluate our approach, we make use of two scenarios: platooning and silent testing. Both of the subsections follow the same approach. We first give a high level description of the corresponding use case, model it by making use of the system model proposed in Sect. 4, and finally discuss how to apply the privacy manager described in Sect. 5.

6.1 Scenario 1: Platooning The platooning system handles the intersection management, adjusting speed, and ensuring safe passage through the intersection. Also, at intersections and highway exits, vehicles leaving the platoon are managed. After a vehicle leaves the platoon, the remaining vehicles tighten their formation. Platoon Dissolution (PD) At the end of the platoon traffic service or when the platoon dissolves, vehicles return to the individual driving mode. They progressively increase the distance between themselves and regain control over their speed and direction, effectively dissolving the platoon. The PSP is notified of the exit, updating the platoon's composition as needed.

6.1.2 Modeling. In this subsection, we elucidate the platooning use case by utilizing the system model as a guiding framework. The platoon services involve key entities, namely, the Platoon Service Provider (PSP), and Platoon Leader, and Platoon Follower entities which are both vehicles. PSP is a central orchestrator of the platooning system. Its role encompasses the coordination, communication, and management of the platooning process. The Platoon Leader assumes a pivotal role within the platooning ecosystem. This entity is responsible for setting the pace, trajectory, and maintaining a consistent speed while leading the platoon. Equipped with advanced sensors, vehicle-to-vehicle (V2V) communication modules, and adaptive control systems, the Platoon Leader creates a stable and synchronized driving environment. The Platoon Leader continuously transmits real-time data to the Platoon Service Provider, facilitating dynamic adjustments to the platoon's composition and behavior. The Platoon Follower is an integral component of the platooning configuration, trailing behind the Platoon Leader. Leveraging V2V communication systems and sensor technologies, the Platoon Follower closely monitors the actions of the Platoon Leader and adjusts its driving behavior accordingly. In the context of our trust model, we assume that the PSP, Platoon Leader, and Platoon

Follower entities are all semi-honest entities. These entities adhere to the protocol correctly but may attempt to deduce sensitive information. Since the main area of interest is the interaction of the vehicles and the PSP, we do not have an application for the functional or topological model in this scenario.

Based on the diverse platooning operations outlined above, communication modes for Platooning services can be categorized into IN-OUT, OUT-IN, and IN-OUT-IN configurations. In the case of IN-OUT communication, the PGC and PD are included. Here, Platoon Followers transmit their data to the PSP and/or the Platoon Leader. In OUT-IN communications, we observe solely the PSO operations, where vehicles exclusively receive synchronization instructions from the Platoon Leader. On the other hand, IN-OUT-IN communications encompass the remaining operations, namely PF, MC, and IM. In these instances, there is an active interaction between the vehicles and the PSP and/or Platoon Leader to execute specific tasks.

6.1.3 Applying the privacy manager. As detailed previously, the requisite planning use case comprises six primary operations that vehicles undergo: PGC, PF, PSO, MC, IM, and PD. In this segment, we examine platooning services from the perspective of the privacy manager. This examination elucidates how personal or sensitive data are safeguarded throughout each of these operations. To achieve this goal, we rely on the PM description provided in Sect. 5. The PM is delineated into four distinct modes within the vehicle for interacting with the PM: direct access, PET application, computation from raw data, and combination.

In the context of direct access, both OEM and PSP entities require vital client information during the subscription to the platoon use case. This essential data includes client IDs, addresses, payment details, and more, all of which will be used for the purpose of client billing.

The PET application is generally divided into three parts:

Anonymization By using pseudonyms or temporary identifiers for vehicles within a platoon, PETs can prevent the direct linkage of specific vehicles to their real identities. Encryption By establishing encrypted communication channels between platooning vehicles to prevent unauthorized access to sensitive data, ensuring that only authorized vehicles within the platoon can exchange information securely. Perturbation Implementing differential privacy techniques can add controlled noise to data shared among platooning vehicles. This ensures that while useful insights can still be derived from the shared data, the privacy of individual vehicles and their passengers is preserved. The Operations PGC, PF, PSO, MC, IM, and PD each employ PETs to uphold data privacy. These operations utilize one of the three types of PETs [START_REF] Garrido | Revealing the landscape of privacyenhancing technologies in the context of data markets for the IoT: A systematic literature review[END_REF]. For instance, Homomorphic Encryption can be employed to encrypt data, which is then sent to the PSP for computation. The PSP can execute these computations on encrypted data without gaining access to any specifics about the vehicles. This approach is analogous to the application of Operation PF in work of Chah et al. [START_REF] Chah | H3PC: Enhanced Security and Privacy-Preserving Platoon Construction Based on Fully Homomorphic Encryption[END_REF]. The data is homomorphically encrypted, and then the target acceleration is obtained through this homomorphic operation. The homomorphic encryption and key management processes will be seamlessly integrated into the privacy manager. This strategic decision ensures that any application utilizing the privacy manager will not be required to independently implement these security measures. By centralizing encryption and key management within the privacy manager, redundancy is eliminated, optimizing efficiency and reducing the need for multiple implementations across various applications. This streamlined approach not only enhances security but also promotes a more cohesive and resource-efficient system for diverse applications that leverage the privacy manager.

The combination of PET application and computation from raw data is used during the PGC operation when the PSP needs only the intersection of all vehicles without knowing their real position. and MC operation, to ensure proper platoon behavior, the leader must maintain real-time communication with the PSP. The PSP should only have access to data pertaining to the conditions and behavior of the platoon.

The data utilized during platooning services varies depending on the previously mentioned operations. For example, the operation PF needs indirect identification data sets, such as location information and vehicle material details, to facilitate the formation of vehicle platoons (cf. Chah et al. [START_REF] Chah | H3PC: Enhanced Security and Privacy-Preserving Platoon Construction Based on Fully Homomorphic Encryption[END_REF] for more details).

6.2 Scenario 2: Silent Testing 6.2.1 Description. Silent Testing is a test method that leverages data on automated vehicles (AVs) from a customer fleet. This section introduces the Silent Testing use case and describes different logical components of a Silent Testing system. Wang [START_REF] Wang | Silent Testing for Safety Validation of Automated Driving in Field Operation[END_REF] summarizes several concepts related to the topic of Silent Testing as available in recent research and industry. Although different terms and concepts are used, the common approach in the mentioned sources and which we in the following refer to as Silent Testing is to monitor a System under Test (SuT) in real-world conditions on public roads, but without control of the vehicle's actuators and interference with other safety relevant systems of the AV. A human driver or a validated automated driving system are performing the actual driving task in the AV with the running SuT, but driver and passengers do not actively participate in the monitoring activities of Silent Testing in any way. With these restrictions, Silent Testing does not pose any safety risk for the passengers of the AV and the environment. One main use case of the collected data from the customer fleet is the safety validation of an AV, but it can serve as an input for continuous software improvements of a defined SuT as well, for example in the form of training data for neural networks.

The data collections with Silent Testing vary highly with the specific monitoring and development goals. In the following, we therefore provide an exemplary, but non-comprehensive description of the different logical components of the Silent Testing System following the dissertation from Wang on Silent Testing with the "Virtual Assessment of Automation in Field Operation" (VAAFO) approach [START_REF] Wang | Silent Testing for Safety Validation of Automated Driving in Field Operation[END_REF][START_REF] Wang | Online safety assessment of automated vehicles using silent testing[END_REF], but also considering efforts from the industry on data collections with a customer fleet, as described in a Tesla patent on training data collection for neural network optimization [START_REF] Karpathy | System and method for obtaining training data[END_REF] and in a press release from CARIAD on an intelligent data acquisition method named Big Loop [START_REF] Sicklinger | How the Big Loop powers data-driven development for ADAS/AD[END_REF].

Current implementations of the Silent Testing concept in general consist of hardware and software in the customer vehicle and a cloud backend. In the vehicle, the Silent Testing SuT as an already released or unreleased software is evaluated against the use case specific monitoring goals with a Silent Testing trigger component. This Silent Testing trigger component uses data from the SuT, an already released software version that is running in parallel or other reference data created by the Silent Testing system as an input for monitoring of the SuT in real-time. In the next step, the activation of a Silent Testing trigger is communicated to a Silent Testing ring buffer. This component continuously buffers data snapshots from the SuT, a released software version and further reference data required for safety validation, simulation or other data analytics methods in a specific Silent Testing use case. Tesla and CARIAD specifically describe the use case of capturing sensor information like camera images of the surrounding in cases where the AVs neural networks require additional training data for optimized performance. These data samples can be enhanced with additional metadata like the vehicle's location or vehicle dynamics information. An active trigger initiates the transfer of the data that is temporarily stored in the vehicle's Silent Testing buffer to the Silent Testing cloud backend via a connectivity module. The purpose of the Silent Testing cloud backend is to distribute the collected data to the respective stakeholders for evaluation. Furthermore, new Silent Testing triggers and data collection requests can be defined here and deployed again to the customer fleet, enabling continuous data driven development.

Modeling.

The involved entities consist of the vehicle as the SuT and a service provider making use of a cloud backend. Within the vehicle the levels of ECU, HPC and the In-Vehicle-Architecture are relevant to follow the information flow of raw data. Regarding the Vehicle-2-X layer, only the Vehicle-2-Service level is concerned as we do not consider any interaction with other devices of the driver or other road users for this scenario. From a functional view, the provided functionality is part of the High-Performance Computer(s) and in the diagnosis, mainly because of the data logging and evaluation taking place. To which degree the topological architecture is concerned will depend on the very specific function evaluated. It might help again for considering the information flow, but our described use case is not detailed enough to either make use of it or rule out its assistance. Regarding the communication, the communication is triggered inside the vehicle by the silent testing trigger component and then submits data to the service provider. Therefore, it is in the category of IN-OUT communication. The vehicle itself should be considered as trusted. If the silent testing service provider can be seen as trusted, will mostly depend on the underlying service which should be tested or improved. If some basic functionality of the vehicle is considered, because an original equipment manufacturer (OEM) is testing its services, the OEM can be considered as a trusted party. If the service is provided by a third party, it is not that clear and also a semi-trusted relationship could be considered. Whereas an untrusted party should not get access to the data considered in this use case, as it in many cases also allows to conclude further information about the vehicle and its driver. The question if a direct or indirect identification is possible will again depend on the exact function evaluated. Most likely, indirect identification will be possible, if the tests are linked to specific vehicles, then also direct identification will be possible.

6.2.3

Applying the privacy manager. The application of the privacy manager is in this scenario again depending on the specific target function which will be evaluated by the SuT. It would be possible to add some noise to the collected data via the privacy manager, to encrypt the data or to use it for some multi-party computation. As the main use case consists of the collection of specific raw data to investigate flaws in certain computations/algorithms separating the computation from the application itself will most likely not be possible without diminishing the desired result in this use case. However, in most cases the service provider will be trusted, i. e. if the service provider is trying to test or improve some algorithms influencing the driving, thus safety critical functions. Therefore, not trusting the service provider would lead to more serious problems for the users than risking their privacy.

DISCUSSION

The use of the system model was straight forward. As expected not all parts of the model are needed for the scenarios we investigated, but we were able to model both scenarios without major difficulties. The larger challenge was to apply the privacy manager. Especially in the silent testing use case, the main result was that even with a more general approach like the privacy manager, the decision how privacy can be protected aka which of its operation modes can be used, depends on details of the scenario. In this case: the specific target function which should be evaluated. Specifically in this use case, it also showed that trying to keep the raw data secret from an application respectively a third party might not work in all cases without limiting the desired goal. While we can argue in this use case that the service provider should be trusted, there might be other scenarios where this is not the case.

Limitations

While our proposed approach of integrating a holistic privacy concept via the privacy manager in the architecture of the vehicle offers several advantages to make the implementation of privacy policies more efficient, it does not come without limitations.

One of the limitations of our work is certainly that as of today we do not have a prototype implemented. This results in several unknowns: (i) Even if our proposal offers a more lightweight way for applications to make use of PETs. It might still be hard for developers to select the most appropriate or an even suitable PET [START_REF] Rannenberg | Study on the technical evaluation of de-identification procedures for personal data in the automotive sector[END_REF]. Our work also only covers data processing in the vehicle and we do not tackle the challenge of how to select a secure and privacyfriendly cloud service [START_REF] Pape | Selecting a Secure Cloud Provider: An Empirical Study and Multi Criteria Approach[END_REF][START_REF] Pape | An Insight into Decisive Factors in Cloud Provider Selection with a Focus on Security[END_REF] or how a customer could asses it [START_REF] Bleikertz | Defining the Cloud Battlefield -Supporting Security Assessments by Cloud Customers[END_REF]. (ii) Another limitation concerns the approach to separate the computational logic on raw data from the application. While it may be feasible in many situations, approaches based on distributed machine learning methods like federated learning [START_REF] Li | Federated learning: Challenges, methods, and future directions[END_REF] could not benefit from it and would still need access to the raw data to continue training their network. (iii) Furthermore, adding noise to the data, e. g. for differential privacy [START_REF] Geng | The optimal noise-adding mechanism in differential privacy[END_REF] is a difficult challenge and might need some interaction with the application: Since the PM does not know about the target function which needs to be evaluated for the application to work, it is hard to decide for the PM which type or amount of noise [START_REF] Tronnier | A discussion on ethical cybersecurity issues in digital service chains[END_REF] to add without impacting the functionality.

Thus, if the privacy manager can be successfully applied might be highly specific and needs to be evaluated for each individual use case.

Even if applied correctly, our proposed approach is not able to prevent all privacy incidents: One example would be parties who got legitimate access to certain data and then use it for other purposes (cf. [START_REF] Biddle | Lexisnexis is selling your personal data to ice so it can try to predict crimes[END_REF][START_REF] Farivar | Peeping TomTom[END_REF]), i. e. sell it to law enforcement agencies, or leak the data due to insecure or misconfigured systems (cf. [START_REF] Toyota | Apology and Notice Concerning Newly Discovered Potential Data Leakage of Customer Information Due to Cloud Settings[END_REF]). Another example are requests from the police, e. g. for self-driving car footage for video evidence [START_REF] Love | Police Are Requesting Self-Driving Car Footage for Video Evidence[END_REF][START_REF] Schneier | Self-Driving Cars Are Surveillance Cameras on Wheels[END_REF] which is a non-technical problem which is not covered by our approach. It rather raises legal and ethical questions (cf. Tronnier et al. [START_REF] Tronnier | A discussion on ethical cybersecurity issues in digital service chains[END_REF]) which are not in scope of our work. In the same manner, it is unclear how the privacy manager and its integrated PETs would affect the users' trust [START_REF] Harborth | Examining Technology Use Factors of Privacy-Enhancing Technologies: The Role of Perceived Anonymity and Trust[END_REF][START_REF] Harborth | JonDonym Users' Information Privacy Concerns[END_REF][START_REF] Harborth | How Privacy Concerns and Trust and Risk Beliefs Influence Users' Intentions to Use Privacy-Enhancing Technologies -The Case of Tor[END_REF], the user's willingness to pay for PETs [START_REF] Harborth | Why Do People Pay for Privacy-Enhancing Technologies? The Case of Tor and JonDonym?[END_REF] or the companies' intentions to handle the data. The latter has recently been investigated [START_REF] Mozilla | Privacy Nightmare on Wheels': Every Car Brand Reviewed By Mozilla -Including Ford, Volkswagen and Toyota -Flunks Privacy Test[END_REF] for cars with all reviewed brands receiving privacy warning labels. However, the researchers investigated only privacy policies, company websites, news reports, research whitepapers, app store entries, and customer reviews, but not the systems respectively vehicles themselves.

CONCLUSION AND FUTURE WORK

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 spoting suitable locations to apply PETs. A subsequent contribution is the concept of our privacy manager which eases the application of PETs for applications and provides a way to separate the computations on raw data and the application logic. Our evaluation by applying the system model and the privacy manager to two distinct use cases shows that our approach is feasible and supports the integration of privacy.

For future work, a valuable contribution could be to specifically think of scenarios making use of machine learning in a way that the system continuously trains its model. As discussed in the limitation section, this might be a requirement where the computation on raw data and the application can not easily be separated. Therefore, an additional operation mode could be needed which not only allows to share the results of a computation but perhaps allows to train a machine learning model, e. g. by making use of federated learning.

Furthermore, we intent to built a prototype of the privacy manager and demonstrate that it is applicable on recent automotive computation systems. For that purpose, we also aim to port or implement suitable PET libraries and demonstrate that the computational power is sufficient during runtime.

Figure 1 :

 1 Figure 1: System Model Overview

  Vehicle-2-X (Receiving) Data sent to the vehicle, which may be of informative nature or expected to trigger a certain action. Examples of informative data are messages sent by RSUs over V2I communication, e.g., for warning about a traffic jam ahead. Examples of data triggering actions include key fob unlocking or remotely starting the car, as well as V2X information warning about an impending collision, thus requiring a braking maneuver. IN-OUT-IN Service-2-Vehicle (Interaction) Data which is received by the vehicle as a response of a previous transmission, with the potential of influencing decision-making processes, within the vehicle. An example of this are enhanced navigation systems, which constantly monitor traffic conditions and control the given route directions. OUT-IN-OUT Vehicle-2-Service (Interaction) Data which is received by the service as a response of a previous transmission, with the potential of influencing privacy leakage through the service

Figure 2 :

 2 Figure 2: Functional Architecture

Figure 3 :

 3 Figure 3: Topological Architecture

Figure 4 :

 4 Figure 4: System Model Communication

Table 1 :

 1 Level Definitions of the System Model

	Level	Definition
	ECU, HPC

Table 2 :

 2 Communication ModelData generated inside a vehicle, which is necessary for a smooth vehicle operation and for the availability of certain services. However, this data is not transmitted outside of the vehicle. This type of data is usually not stored in long term memory and includes data generation which is required by law, such as information required by Event Data Recorders (EDRs).

	Communication	Level	Definition
	IN-IN	ECU-2-ECU
	IN-OUT	Vehicle-2-X (Sending)

  This could work with services like Pay-as-you-drive (IN-OUT) where only the result of the driving style is crucial, rather than sharing sensitive data for the computation itself. The same applies to services like Attention Monitoring (IN-IN) where the vehicle only needs to know the attentiveness of the driver rather than having access to driver monitoring data (e.g., in-cabin camera). Combination This operation mode is a combination of PET application and Computation from raw data. An example for that is if the application should not have access to the raw data and additionally its capacity to transfer data outside of the vehicle should be limited.

  Platooning Formation (PF) It occurs after selecting the group of vehicles and the vehicle leader. Following the conditions provided by the PSP, allows the vehicles to position themselves optimally within the platoon smoothly. The vehicles automatically position themselves behind the leader, maintaining a safe and constant distance between them. Subsequently, vehicles establish communication links to share data and coordinate their movements. Platoon Synchronization/Operation (PSO) Once the vehicles are in position, in a single line, synchronization takes place. The Platoon Leader is in charge of setting the speed and maintaining a safe distance, ensuring synchronized movement. Monitoring and Control (MC) Throughout the platoon operation, PSP continually monitors the vehicles' status and environment. The control system ensures that vehicles maintain the required formation, adhere to traffic conditions, and follow safety protocols. If anomalies or safety risks are detected, appropriate steps are taken to correct them. The vehicle leader must maintain real-time communication with the PSP for analysis. Intersection Management (IM) The platoon may need to be able to interact with traffic signals or coordinate with other platoons.

	6.1.1 Description. Vehicle platooning, a technology-enabled strat-
	egy in the realm of intelligent transportation systems, is gaining
	prominence for its ability to streamline traffic patterns and minimize
	environmental impact. Platoon Services have multiple operations
	that we group under the following terms: Platoon Group Configu-
	ration, Platooning Formation, Platoon Synchronization/Operation,
	Monitoring and Control, Intersection Management, and Platoon
	Dissolution. This whole area of services must be reviewed from the
	privacy-preserving standpoint. These operations generally involve
	the following steps:
	Platoon Group Configuration (PGC) Participating vehicles send
	a request to the server to indicate their will to join a platoon.
	PSP proposes that drivers set up groups of platoons, accord-
	ing to different conditions on the vehicles. Some information
	about the vehicle and the platoon are compared, such as
	destination, iteration, vehicle position, speed, and behavior

of each platoon, etc. The Platoon Leader, usually a vehicle with advanced communication and control capabilities, coordinates the composition of the platoon based on factors such as the vehicle type, the destination, and the compatibility.

such as UN Regulations No. 155 [52] and 156 [53] and the according international standards ISO/SAE

[13], ISO PAS 5112[14], ISO 24089[15]

https://autopsy-project.eu/

ACKNOWLEDGMENTS

This work was suported by the Federal Ministry of Education and Research, Germany (BMBF) under grant number 16KIS1382 and the Agence Nationale de la Recherche, France (ANR).


Philippe Loubaton

Testing Uncorrelation of Multi-Antenna Signals Using Linear Spectral Statistics of the Spatio-Temporal Sample Autocorrelation Matrix

Keywords: Correlation tests, multivariate time series, random matrix theory, wideband signal detection

published or not. The documents may come

INTRODUCTION

We consider the problem of testing whether a collection of wideband signals received by a large number of spatially distributed antennas are correlated. The main motivation for this problem in array signal processing is the detection of the presence of wideband directional sources using a large number of receivers that are subject to calibration and synchronization errors. Since the received signals are generally wideband, they can be best modeled as time series. Under these challenging circumstances, and given the difficulty of establishing valid signal models for such a general propagation environment, one possible way of detecting the presence of directional signals is by establishing whether the signals that are measured at the different antennas are statistically independent. If the signals are assumed to be zero-mean and Gaussian distributed, the problem is equivalent to testing uncorrelation among the different time series.

Uncorrelation tests among multiple time series have traditionally been formulated from two different perspectives, namely frequencydomain approaches and lag-domain approaches. Frequency-domain methods establish that the different time series are uncorrelated when the spectral coherence matrix is equal to the identity over all the spectrum, e.g. [START_REF] Wahba | Some tests of independence for stationary multivariate time series[END_REF][START_REF] Taniguchi | Nonparametric approach for non-Gaussian vector stationary processes[END_REF][START_REF] Eichler | A frequency-domain based test for noncorrelation between stationary time series[END_REF][START_REF] Eichler | Testing nonparametric and semiparametric hypotheses in vector stationary processes[END_REF]. Lag-domain approaches, on the contrary, directly examine the autocorrelation coefficients between the This work has been partially funded by the French government through the Bézout Labex (ANR-10-LABX-58) and the HIDITSA project (ANR-17-CE40-0003) and by the Spanish government under the Aristides project (RTI2018-099722-B-I00).

different time series taken at distinct time lags, e.g. [START_REF] Haugh | Checking the independence of two covariancestationary time series: a univariate residual cross-correlation approach[END_REF][START_REF] Hong | Testing for independence between two covariance stationary time series[END_REF][START_REF] Duchesne | Robust tests for independence of two time series[END_REF][START_REF] Kim | A test for independence of two stationary infinite order autoregressive processes[END_REF][START_REF] Himdi | Tests for non-norrelation of two multivariate time series: A nonparametric approach[END_REF]. In this paper, we focus on this second family of approaches, which directly work on the sample autocorrelation matrix series between pairs of time series. For a similar treatment of frequency-domain approaches, the reader is referred to [START_REF] Loubaton | Large random matrix approach for testing independence of a large number of Gaussian time series[END_REF][START_REF] Rosuel | On The Frequency Domain Detection of High Dimensional Time Series[END_REF].

Let ym[n] denote the signal that is captured at the mth antenna, m = 1, . . . , M, where M is the total number of receive antennas. Assuming that the signals are complex circularly symmetric Gaussian stationary processes with zero mean, they will be uncorrelated if and only if

E [ym[n + ]y * k [n]] = rm( )δ m=k (1)
for all ∈ Z, where (rm( )) ∈Z is the covariance sequence of the mth received signal, which can be expressed as the inverse Fourier transform of the associated spectral density Sm (ν), namely

rm ( ) = 1 0 Sm (ν) e 2πiν dν. (2)
In practice, the right hand side of (1) is replaced with the empirical mean estimate taken from N consecutive samples of the received signals, that is rm,m (n + , n) where

rm,m n, n = 1 N N -1 n=0 ym[n]y * m [n ]
which is computed for a finite span of time lags, namely = -(L -1) , . . . , L -1 for some design integer L. In order to formalize the construction of uncorrelation tests based on the above empirical estimates, let us consider the ML × ML spatio-temporal empirical covariance matrix RL. This matrix is structured in blocks of size L × L associated to each pair of series. More specifically, the

L × L block matrix in the position (m, m ) for 1 ≤ m, m ≤ M can be denoted as R (m,m ) L
and corresponds to the sample crosscovariance matrix between the signals received at antennas m and m . The (l1, l2)th entry of this matrix can therefore be written as

R (m,m ) L l 1 ,l 2 = rm,m (n + l1, n + l2) .
If we keep M, L fixed and let N → ∞ assuming that the signals are independent, the spatio-temporal sample covariance matrix RL converges almost surely to a block diagonal matrix with L × L Toeplitz blocks Rm,L, m = 1, . . . , M, with entries

(Rm,L) l 1 ,l 2 = rm(l1 -l2). ( 3
)
This means that, if N is sufficiently large, one can test whether the signals are uncorrelated by checking how far RL is from a block diagonal matrix. This is the main motivation for considering the sample spatio-temporal correlation matrix, defined as

Rcorr,L = B -1/2 L RL B -1/2 L
where BL is the block diagonal matrix with blocks R (m,m) L

, m = 1, . . . , M. If N is sufficiently large with respect to the other parameters (in the sense that ML/N 1) one would expect Rcorr,L to be close to the identity matrix provided that the observed signals are uncorrelated.

A key aspect of the above discussion is how to choose the maximum tested lag L in a practical setting. On the one hand, L should be sufficiently large, because this allows to identify correlations among signals collected at different antennas associated to large time lags. For example, if a jammer source transmits white noise and is received at two different antennas with a time difference of more than L samples, it will be perceived as completely uncorrelated signals at these two antennas. On the other hand, L should be chosen sufficiently small so that ML/N 1 in order to make the estimation error Rcorr,L -IML reasonably low when the signals are indeed uncorrelated. The situation is specially challenging when the number of collected signals M is large and the number of observations N is limited, because the condition ML/N 1 requires the selection of a small value for L, thus drastically limiting the efficiency of the uncorrelation tests based on Rcorr,L -IML . Our objective here is to study the spectral behavior of Rcorr,L in asymptotic regimes where M, N, L converge towards +∞ in such a way that cN = ML N converges towards a non zero constant c * ∈ (0, +∞). This asymptotic regime is much more relevant than conventional asymptotics (N → ∞ for fixed ML) because it corresponds to a situation where size of the spatio-temporal sample autocorrelation matrix Rcorr,L is comparable in magnitude to the number of samples used in the underlying sample covariance estimators.

There exist several studies in the literature that have specifically focused on this large dimensional asymptotic regime (see, e.g. [START_REF] Jiang | Central limit theorems for classical likelihood ratio tests for high-dimensional distributions[END_REF][START_REF] Dette | Likelihood ratio tests for many groups in high dimensions[END_REF][START_REF] Mestre | Correlation tests and linear spectral statistics of the sample correlation matrix[END_REF]), although most of them have considered the case where L is fixed. In fact, a number of previous works have investigated the behavior of the autocovariance matrix for a given fixed time lag (see [START_REF] Jin | Limited spectral distribution of a symmetrised auto-cross covariance matrices[END_REF][START_REF] Li | On singular value distribution of largedimensional autocovariance matrices[END_REF][START_REF] Liu | On the Marcenko-Pastur law for linear time series[END_REF][START_REF] Bhattachargee | Large sample behaviour of highdimensional autocovariance matrices[END_REF][START_REF] Jiang | The limiting distributions of eigenvalues of sample correlation matrices[END_REF][START_REF] Nowak | Spectra of large time-lagged correlation matrices from random matrix theory[END_REF][START_REF] Loubaton | On the behaviour of large autocovariance matrices between the past and the future[END_REF]). The case of large L has been investigated in [START_REF] Loubaton | On the almost sure location of the singular values of certain Gaussian block-Hankel large random matrices[END_REF] and [START_REF] Loubaton | Spectral convergence of large block-Hankel Gaussian random matrices[END_REF], which also addressed the asymptotic regime considered in the present paper. More specifically, [START_REF] Loubaton | On the almost sure location of the singular values of certain Gaussian block-Hankel large random matrices[END_REF] assumed that the M mutually independent time series are i.i.d. Gaussian white noise and established that the empirical eigenvalue distribution of the sample spatio-temporal covariance matrix RL converges to the Marchenko-Pastur distribution. In [START_REF] Loubaton | Spectral convergence of large block-Hankel Gaussian random matrices[END_REF], a more general situation in which the different time series were independent but were allowed to present non-trivial statistical dependencies in the time domain. Under the present asymptotic conditions, it was established that the empirical eigenvalue distribution has also a deterministic behavior.

In this paper, we propose to study the behavior of spectral statistics built from the eigenvalues of Rcorr,L, which will be denoted by ( λk,N ) k=1,...,M L . More specifically, we will consider linear spectral statistics (LSS) built from this matrix, which take the general form

φN = 1 ML Tr φ Rcorr,L = 1 ML ML k=1 φ λk,N (4)
where φ is assumed to be a sufficiently smooth function. Our interest is mainly on the behavior of this type of statistics for the characterization of uncorrelation tests under the null hypothesis, which cor-responds to the situation where the different signals are independent but present non-trivial statistical dependence in the time domain.

ASYMPTOTIC DETERMINISTIC EQUIVALENT OF φN

Our objective is to characterize the behavior of linear spectral statistics as given in (4) when the three parameters M, L, N grow without bound. We will strongly rely on the following asymptotic and statistical assumptions. Asymptotic assumptions. We will let M → +∞, N → +∞ in such a way that cN = ML N → c , where 0 < c < +∞, and that L = L(N ) = O(N β ) for some constant β ∈ (0, 1). Special emphasis will be given to the case where β is small. Indeed, the scenario with small β can be associated with configurations operating with a large number of receiving antennas M . In this case, the conventional regime (ML N ) could only be achieved with a very small L, which would seriously limit the correlation identification capabilities among the different received signals.

Statistical assumptions. We will assume that the signals received by the M antennas, that is ym[n], m ≥ 1, are mutually independent, stationary, zero mean and circularly symmetric Gaussian distributed time series with autocovariance sequences (rm(k)) k∈N in (1) and associated spectral densities Sm(ν) as in [START_REF] Taniguchi | Nonparametric approach for non-Gaussian vector stationary processes[END_REF]. We will assume that the spectral densities are uniformly bounded above and below, that is

0 < inf m≥1 min ν∈[0,1] Sm(ν) ≤ sup m≥1 max ν∈[0,1] Sm(ν) < +∞.
Furthermore, the autocovariance sequence rm will be assumed to decay sufficiently fast in the lag domain, so that

sup m≥1 ∞ n=-∞ (1 + |n|) γ 0 |rm(n)| < ∞ (5)
for some γ0 > 0. Finally, if we denote by rM the M -dimensional sequence of covariances, namely rM (k) = [r1(k), . . . , rM (k)] T , we will also need to assume that

sup M ≥1 1 √ M k∈Z rM (k) < +∞.
We will see next that, with exponentially high probability, the empirical eigenvalue distribution of the Rcorr,L has the same asymptotic behavior as a deterministic scalar measure μN (λ) that essentially depends on the autocovariance sequences of the signals received at the M different antennas. This measure will be useful to characterize the asymptotics of the linear spectral statistics φN whenever the autocovariance sequences (or the associated spectral densities) of the different time series are known beforehand. Later, we will see that this deterministic measure μN (λ) can be further approximated by the Marchenko-Pastur distribution of parameter cN , a result that can be used to characterize the asymptotic behavior of φN in the more common situation where the covariance structure of the different signals is unknown.

In order to introduce the measure μN (λ), we need to consider some matrix Toeplitzation operators that were originally used in [START_REF] Loubaton | Spectral convergence of large block-Hankel Gaussian random matrices[END_REF], which inherently depend on the covariance sequences (rm) m≥1 of the received signals. In order to introduce these operators, for ν ∈ [0, 1] and R ∈ N, we define the column vector dR(ν) = 1, e 2iπν , . . . , e 2iπ(R-1)ν T [START_REF] Hong | Testing for independence between two covariance stationary time series[END_REF] and let aR(ν) denote the corresponding normalized vector, i.e. aR(ν) = R -1/2 dR(ν). With these two definitions, we are now able to introduce the Toeplitzation operators used to define the above deterministic measure μN (λ). For a given squared matrix M with dimensions R × R, we define Ψ (m) K (M), m = 1, . . . , M, as the K × K Toeplitz matrix given by

Ψ (m) K (M) = 1 0 Sm (ν) a H R (ν) MaR (ν) dK (ν) d H K (ν) dν.
The above operator is the key building block that defines Ψ and Ψ, which are the ones that determine the master equations that define μN (λ). Indeed, consider an N × N matrix M. We define Ψ (M) as an ML × ML block diagonal matrix with mth diagonal block given by Ψ (m) L (M), namely

Ψ (M) = Bdiag Ψ (1) L (M) , . . . , Ψ (M ) L (M) . ( 7
)
Finally, consider an ML × ML matrix M, and let Mm,m denote its mth L × L diagonal block. We define Ψ (M) as the N × N matrix given by

Ψ (M) = 1 M M m=1 Ψ (m) N (Mm,m) . ( 8
)
Having introduced the above operators, we are now ready to present the master equations that define the deterministic measure μN (λ). Consider a z ∈ C + (the upper complex semiplane) and the following pair of equations in TN (z), TN (z):

TN (z) = - 1 z IML + B -1/2 L Ψ T T N (z) B -1/2 L -1 (9)
TN (z) = - 1 z IN + cN Ψ T B -1/2 L TN (z)B -1/2 L -1 . ( 10
)
where BL is an ML × ML block diagonal matrix with L × L blocks Rm,L, m = 1, . . . , M as defined in (3). It can be shown that there exists a unique pair of solutions TN (z), TN (z) to the above equations in the set of matrix-valued Stieltjes transforms of positive matrix measures carried by R + of sizes ML × ML and N × N respectively. Then, μN (λ) is defined as the deterministic measure with Stieltjes transform tN (z) = (ML) -1 Tr(TN (z)). We recall that the measure μN (λ) can be retrieved from its Stieltjes transform tN (z) via the Stieltjes inverse formula, that is

b a dμN (λ) = lim y→0 + 1 π b a Im [tN (x + iy)] dx
for any two continuity points a, b ∈ R. Having introduced this deterministic measure, we are now in the position to present the first result of this paper, which is proven in [START_REF] Loubation | On the asymptotic behavior of the eigenvalue distribution of block correlation matrices of highdimensional time series[END_REF].

Theorem 1. Consider the above statistical and asymptotic assumptions. Let β < 4/5 and assume that φ is a smooth function with compact support on the positive real axis. Then, for every small > 0 there exists an r > 0 independent of N such that [START_REF] Rosuel | On The Frequency Domain Detection of High Dimensional Time Series[END_REF] for all N sufficiently large.

P φN - R + φ(λ)dμN (λ) > N N min(βγ 0 ,1-β) < e -N r
The above theorem establishes that, with exponentially high probability, linear spectral statistics of the spatio-temporal sample autocorrelation matrix are asymptotically close to a deterministic quantity that can be completely characterized from the deterministic scalar measure μN (λ), with an error term that decays as O(N -min(βγ 0 , 1-β) ). In order to determine the asymptotic deterministic equivalent of the statistic φN , we need the deterministic measure μN (λ), which inherently depends on the spectral densities of the signals received at the different antennas. In most applications, these spectral densities are completely unknown, so that μN (λ) cannot possibly be determined. In these cases, we may consider an additional approximation step, which shows that μN (λ) is asymptotically close to a Marchenko-Pastur distribution of parameter cN , up to an additional deterministic error term.

Before we present this second approximation, it is worth pointing out that the assumption that the function φ has compact support can be relaxed under some special conditions. For example, the above result is equally valid for the function φ(λ) = (λ -1) 2 , which gives rise to the famous Frobenius norm test (sum of the squared modulus of the off-diagonal entries of Rcorr,L), which corresponds to φN = || Rcorr,L -IML|| 2 F . We refer the reader to [24, Remark 6.1] for further details on when Theorem 1 can still be applied to functions without compact support.

APPROXIMATION BY A MARCHENKO-PASTUR LAW

Let us now turn to the more common situation where the spectral densities of the received signals are unknown, so that one has to rely on a less accurate asymptotic approximation of the linear spectral statistic. The following result is established in [START_REF] Loubation | On the asymptotic behavior of the eigenvalue distribution of block correlation matrices of highdimensional time series[END_REF] by using results on orthogonal polynomials associated to the measures Sm(ν)dν [START_REF] Ya | Polynomials Orthogonal on a Circle and Interval[END_REF][START_REF] Simon | Orthogonal Polynomials on the Unit Circle, Part 1: Classical Theory[END_REF]. We will denote by μmp,c N the Marchenko-Pastur distribution with parameter cN = ML N . We recall that μmp,c N is the limit of the empirical eigenvalue distribution of a large random matrix N -1 XX H where X is an ML × N random matrix with i.i.d. entries having zero mean and unit variance.

Theorem 2. Consider the statistical and asymptotic assumptions at the beginning of Section 2. Then, for every γ < γ0, γ = 1 and every compactly supported smooth function φ on the positive real axis, we have

R + φ(λ)dμN (λ) - R + φ(λ)dμmp,c N (λ) < κ 1 N 2β min(γ,1) (12
) for some universal constant κ > 0.

The above theorem basically establishes a further level of approximation of the original linear spectral statistic φN , which can be asymptotically described by the Marchenko-Pastur law (thus not requiring the knowledge of the individual spectral densities Sm(ν)). The price to pay is an additional error term, this time decaying to zero with speed O(N -2β min(γ,1) ). Unfortunately, the error term in [START_REF] Jiang | Central limit theorems for classical likelihood ratio tests for high-dimensional distributions[END_REF] becomes the dominant one as soon as β < 1/3 if γ0 > 1. Note that the situation where β is small (or, equivalently, L M ) is the most relevant asymptotic scenario. Otherwise, the ratio M/N converges quickly towards 0, which in practice represents situations in which M N . Therefore, it may be possible to choose a reasonably large value of L such that ML N 1 and therefore the simpler asymptotic regime where ML N → 0 may be relevant enough. In conclusion, we observe that when β < 1/3 and γ0 > 1, the dominant error incurred by approximating the linear spectra statistic φN as an integral with respect to the Marchenko-Pastur law is in fact an unknown deterministic term as established in [START_REF] Jiang | Central limit theorems for classical likelihood ratio tests for high-dimensional distributions[END_REF].

NUMERICAL VALIDATION

We consider here a simple example in which the M independent time series are all autoregressive processes of order one AR [START_REF] Wahba | Some tests of independence for stationary multivariate time series[END_REF] with parameter ρ and unit power. By this, we mean that we generate each time series independently by the recursion ym

[n + 1] = ρym[n] + em[n] where em[n] ∼ N C (0, 1 -|ρ| 2 )
. We first compare the empirical eigenvalue distribution of the sample cross correlation matrix Rcorr,L with the scalar deterministic measure μN and the Marchenko-Pastur distribution with parameter cN , that is μmp,c N . Figure 1 represents the histogram of the eigenvalues of Rcorr,L together with the densities of μN and μmp,c N for different values of M, N, L. In general terms, we observe that the Marchenko-Pastur law is a very good approximation of the actual empirical eigenvalue distribution, even for relatively low values of M, L. In fact, it is difficult to spot the difference between the two densities of μN and μmp,c N , which appear to be more apparent near the endpoints of their corresponding supports. Next, consider a correlation detection test statistic consisting of the sum of the squared value of all the off-diagonal entries of Rcorr,L. As mentioned above, this corresponds to a linear spectral statistic of Rcorr,L built with the function φ(λ) = (λ -1) 2 . For this particular choice of the function φ(λ), we can establish that

φ(λ)dμN (λ) = cN + cN 1 ML Tr B -1 L Ψ(EN ) (13)
where we have introduced the N × N matrix EN , defined as

EN = 1 0 1 M M m=1 Sm(ν)a H L (ν)R -1 m,L aL(ν) -1 dN (ν)d H N (ν)dν
with Rm,L defined in (3). On the other hand, we can also establish that φ(λ)dμmp,c N (λ) = cN . In the upper plot of Figure 2 we evaluate the error between φN and the corresponding integral of φ(λ) with respect to the Marchenko-Pastur distribution. For each experiment, we fixed the three parameters c , N and β and considered a set of M = [(c N ) [(c N ) β ] time lags, where [x] here denotes the integer that is closest to x. The errors are represented as the square root of the empirical mean of the corresponding normalized difference, averaged over the 10 4 realizations of the AR(1) processes. In the lower plot, we represent the two constituent errors that are characterized in Theorems 1 and 2 respectively. "Error 1" (solid lines) represents the square root of the empirical mean of | φNφ(λ)dμN | 2 , and "Error 2" (dotted lines) represents | φ(λ)dμNφ(λ)dμmp,N |.

These results tend to confirm the fact that the error between the considered statistic and its asymptotic deterministic approximation tends to be dominated by two different phenomena depending on whether M L (large β) or M L (small β). In the fist case, the main contribution to the error corresponds to the term φNφ(λ)dμN (Error 1). We recall that, since the correlation sequence considered here decays exponentially to zero, this error term is dominated by N - (1-β) , which in particular increases with β. Conversely, when M L (small β), the error is dominated by the difference between the two measures μN and μmp,N . We have seen that this error term is dominated by a term of order N -2β , which in particular decreases with β. Observe also that the optimum choice of β in terms of approximation error appears to be close to 1/3, which corresponds to the case where the two error rates coincide.

CONCLUSIONS

We have examined the problem of testing uncorrelation via linear spectral statistics of the spatio-temporal sample autocorrelation matrix under the hypotheses that the signals received at the different antennas are mutually uncorrelated. In the large dimensional regime, these statistics can be well approximated by deterministic equivalents depending on the constituent spectral densities. A closed form expression has been derived for the Stieltjes transform of the deterministic measure associated to this asymptotic equivalent. Finally, it has been shown that (up to an additional error term) one can also express these deterministic equivalents as the corresponding integrals with respect to a Marchenko-Pastur distribution, which do not require the knowledge of the covariance structure of the signals.

Fig. 1 .

 1 Fig. 1. Histogram of the eigenvalues of Rcorr,L in comparison with the distributions μN and μmp,c N for different values of M, N, L with ρ = 0.5. The upper plot corresponds to a situation where cN > 1 whereas the lower plot represents the case cN < 1.

Fig. 2 .

 2 Fig. 2. Evolution of the error of φN with respect to the Marchenko-Pastur limit as a function of β.