Method for processing data of multiple applications of a vehicle by a central privacy manager

Abstract

High-performance computer, apparatus, computer-readable data carrier, computer program and method for processing data of multiple applications of a vehicle by a central privacy manager Embodiments of the present disclosure relate to a high-performance computer, an apparatus, a computer-readable data carrier, a computer program and a method for processing data of multiple applications of a vehicle by a central privacy manager. The method comprises obtaining first data for a first application and second data for a second application. Further, the proposed method suggests obtaining information on privacy and / or application-specific requirements for the first and the second application. The method further includes processing the first data, if necessary, in accordance with the privacy and / or application-specific requirements for the first application and processing the second data, if necessary, in accordance with the specific requirements for the second application. Also, the method comprises providing the processed / unprocessed first and second data for the first and the second application.

Description

[0001] METHOD FOR PROCESSING DATA OF MULTIPLE APPLICATIONS OF A VEHICLE BY A CENTRAL PRIVACY MANAGER

[0002] Description

[0003] High-performance computer, apparatus, computer-readable data carrier, computer program and method for processing data of multiple applications of a vehicle by a central privacy manager

[0004] Embodiments of the present disclosure relate to a high-performance computer, an apparatus, a computer-readable data carrier, a computer program, and a method for processing data of multiple applications of a vehicle by a central privacy manager.

[0005] Rapidly changing digital technologies such as the Internet of Things (loT), cloud technologies, and Artificial Intelligence (Al) 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 and changing to software defined vehicles 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, these changes are a huge challenge to building secure and privacy friendly systems for the automotive industry. As in many other areas, privacy and security concerns play a crucial role in adoption.

[0006] 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.

[0007] Some Automotive System Models describe a system model for automotive applications with a focus on fuel cells. Some approaches propose a system model in the automotive privacy domain. Some other approaches provide a privacy preserving architecture for self-driving cab services which models only one specific scenario whereas it is proposed a more generic system model and architecture which should be applicable in the majority of use cases.

[0008] An exemplary system model for automotive applications is described by Pape, S.; Syed-Winkler, S.; Garcia, A. M.; Chah, B.; Bkakria, A.; Hiller, M.; Walcher, T.; Lombard, A.; Abbas-Turki, A. and Yaich, R.: A Systematic Approach for Automotive Privacy Management. In CSCS '23: ACM Computer Science in Cars Symposium, Darmstadt, Germany, December 5th, 2023, ACM, 2023.

[0009] Automotive Privacy Engineering:

[0010] The autonomous vehicle represents a transformative technological advancement poised to revolutionize 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. There are ethical and privacy challenges inherent to this technological advancement.

[0011] Users express reservations regarding the use of cameras and prefer capacitive proximity sensing sensors instead, reflecting their privacy concerns.

[0012] Accordingly, protocols aim to ensure the privacy and security of users in services like autonomous cabs, ride-sharing, and platooning, 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 addresses the question how to choose a suitable privacy enhancing technology for a given problem.

[0013] Privacy threat elicitation:

[0014] 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 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, Non-repudiation, Detectability, and Disclosure of information, and soft privacy threats, including Unawareness and Non-compliance. Some approaches provide a comprehensive privacy threat analysis (employing the LINDDUN methodology) of the general architecture of connected and autonomous vehicles (CAVs) aimed at identifying privacy risks in accordance with formal privacy requirements. Extensions of such concepts focus on a specific use case to assist manufacturers in implementing privacy requirements and enhancing privacy protection. Approaches of threat elicitation combine asset-oriented ISO approach with the threat-oriented STRIDE approach tailored to the level of specific car brand and the need to extend the EN ISA’s privacy threats.

[0015] However, existing approaches may be too restrictive or revealing. This may lead to unnecessary computational effort and / or privacy issues. Hence, there may be a demand for an improved concept for privacy management. This demand may be satisfied by the subject-matter of the appended independent claims. The dependent claims disclose optional embodiments of the independent claims.

[0016] Embodiments of the present disclosure provide a method for processing data of multiple applications of a vehicle by a central privacy manager. The method comprises obtaining first data for a first application and second data for a second application. Further, the proposed method suggests obtaining information on privacy and / or application-specific requirements for the first and the second application. The method further includes processing the first data, if necessary, in accordance with the privacy and / or application-specific requirements for the first application and processing the second data, if necessary, in accordance with the privacy and / or application-specific requirements for the second application. Also, the method comprises providing the processed / unprocessed first and second data for the first and the second application. In this way, the first and second data may be tailored to the first and the second application in consideration of different privacy and / or application-specific requirements. In doing so, e.g., processing of superfluous data may be avoided and / or the use of private data may be reduced to a minimum required for a certain application.

[0017] In practice, the first and / or second data may comprise sensor data and / or personal data of a user.

[0018] The proposed approach may be applied in different applications. Exemplary applications include communication applications, e.g., inter- and / or intra-vehicular communication as well as perception, and / or motion.

[0019] Accordingly, providing the processed / unprocessed first and the second data may comprise providing the processed / unprocessed first and / or the second data for the communication with an external device separate from the vehicle. As a skilled person having benefit from the present disclosure will appreciate, various processing techniques may be applied for processing the first and / or second data.

[0020] In some embodiments, processing the first data comprises selecting one or more first privacy-enhancing technologies (PETs) based on the privacy and / or application-specific requirements for the first application, and applying the selected first PETs on the first data. Accordingly, processing the second data may comprise selecting one or more second PETs based on the privacy and / or application-specific requirements for the second application, and applying the selected second PETs on the second data.

[0021] In practice, the first and second PETs may include an anonymization algorithm, encryption algorithm, multi-party computation, and / or a perturbation algorithm.

[0022] The skilled person will also appreciate that proposed approach may be applied for various applications of the vehicle. In some embodiments, such applications may involve an electronic control unit (ECU) and / or a software application.

[0023] So, the first and / or the second application may involve one or more ECUs and / or one or more software applications.

[0024] For providing the unprocessed / process data, it may be transmitted to the application. Alternatively, providing the processed / unprocessed first and second data may comprise granting access to the first and / or second data to an external device separate from the vehicle. In doing so, the first and / or second data may be stored on an internal storage of the vehicle or a cloud.

[0025] In some embodiments, the applications and the privacy manager may be implemented in separate software applications. So, for example, obtaining the first and the second data comprises receiving the first data from a first software application for the first application and receiving the second data from a second software application for the second application, and the privacy manager is implemented in a third software application. This way, implementations of present disclosure may profit from such modular structure.

[0026] In some embodiments, the method comprises applying one or more libraries for processing the first and second data. This case, the privacy manager may be privileged to obtain the processed first and second data from the libraries.

[0027] Other embodiments provide a computer program comprising instructions which, when the computer program is executed by a computer, cause the computer to carry out an embodiment of the proposed method.

[0028] In further embodiments provide a computer-readable data carrier having stored thereon such computer program.

[0029] Also, embodiments provide an apparatus comprising one or more interfaces for communication and a data processing circuit configured to execute an embodiment of the proposed method.

[0030] The skilled person will appreciate that the proposed approach may be applied in a high-performance computer (HPC) for a vehicle.

[0031] Accordingly, further embodiments provide an HPC for a vehicle. The HPC comprises an embodiment of the proposed apparatus.

[0032] Brief description of the drawings

[0033] Fig. 1 shows a flow chart schematically illustrating an embodiment of a method for processing data of multiple applications of a vehicle by a central privacy manager;

[0034] Fig. 2 shows an exemplary use case of the proposed approach; Fig. 3 shows a block diagram schematically illustrating an application of the proposed approach; and

[0035] Fig. 4 shows a block diagram schematically illustrating an embodiment of an apparatus in accordance with the proposed approach.

[0036] Further, embodiments are now described with reference to the attached drawings. It should be noted that the embodiments illustrated by the referenced drawings show merely optional embodiments as an example and that the scope of the present disclosure is by no means limited to the embodiments presented.

[0037] Fig. 1 schematically visualizes an embodiment of a method 100 for processing data of multiple applications of a vehicle by a central privacy manager.

[0038] Method 100 comprises obtaining 110 first data for a first application and second data for a second application and obtaining 120 information on privacy and / or application-specific requirements for the first and the second application.

[0039] The first and / or second data may comprise sensor data. In practice, the vehicle may be equipped with one or more sensors for monitoring and / or preceding its environment (e.g., for autonomous or assisted driving or parking). Accordingly, the first and / or the second data may be obtained from one or more sensors of the vehicle and / or a storage for such sensor data. Exemplary sensors for the vehicle include one or more cameras, distance sensors, ultrasonic sensors, radar sensors, lidar sensors, and / or the like.

[0040] Additionally or alternatively first and / or the second data may include personal data of a user. Such personal data, e.g., includes the name, the age, the address, the date of birth or any other personal data.

[0041] The information on privacy and / or application-specific requirements for the first and the second application may include information on a trustworthiness of the first and / or the second application and may indicate what information may be required and / or may be kept secret for the first and the second application. For example, such information indicates whether the first and / or second application involves an un-trusted party, a semi-trusted party, and / or a trusted party, as laid out in more detail later.

[0042] As well, the information on the information on privacy and / or application-specific requirements may indicate which information from the first and / or the second data may be superfluous for the first and / or the second application and / or which information may be technically required.

[0043] Method 100 further suggests processing 130 the first data, if necessary, in accordance with the privacy and / or application-specific requirements for the first application and processing 140 the second data, if necessary, in accordance with the privacy and / or application-specific requirements for the second application. In doing so, the first and / or the second data may be reduced, anonymized, perturbed, encrypted, and / or processed using multi-party computation in order to prepare the first and / or the second data for the first and the second application, if necessary, while the privacy is preserved. In this way, the first and / or the second data may be reduced to the minimum of information required for the first and / or the second application such that a maximum of privacy is preserved.

[0044] In practice, e.g., positional information which may be transmitted to a semi- or un-trusted party may be perturbed or reduced, and personal information may be deleted as far as appropriate for the first and / or the second application.

[0045] For example, for an autonomous driving or driving assistance system, e.g., it may be relevant if the driver is awake and / or pays attention. For this, sensor data of a cabin monitoring camera may be analyzed. However, the autonomous driving or driving assistance system may only need information about the attention state of the driver but not the raw sensor data which may include sensitive information as well. So, the information on the privacy and / or application-specific requirements may indicate that information about the attention of the driver is required. Accordingly, the information on the attention of the driver may be extracted from the sensor data of the camera and the extracted information is provided to the autonomous driving or driving assistance system.

[0046] In contrast, another application, e.g., an environmental perception system may require raw sensor data of the environment from environmental sensors to characterize the environment in detail, e.g., for autonomous driving, which is why the sensor data is forwarded unprocessed to the environmental perception system.

[0047] So, according to the proposed approach, the first data (sensor data from the cabin monitoring camera) may be processed for privacy and according to technical requirements while the second data (sensor data from environmental sensors) may be forwarded unprocessed.

[0048] In other example, both, the first and the second data may be processed or left unprocessed according to the privacy and / or application-specific requirements of the applications. In other examples, e.g., both applications may demand a certain level of privacy (e.g., for communication with semi- or un-trusted parties) and / or both may only need a certain portion of information (e.g., metadata) from the first and the second data. Vice versa, both, the first and the second data may be left unprocessed, if appropriate.

[0049] Further, method 100 includes providing 150 the processed / unprocessed first and second data for the first and the second application.

[0050] For this, the processed / unprocessed first and second data may be transmitted and / or access to the processed / unprocessed first and the second data is granted. For example, the processed / unprocessed first and second data is transmitted to or made available for a recipient which uses the processed / unprocessed for the respective first or second application. For this, any communication technique and / or protocol may be used to communicate the data with the recipient and / or a local or cloud storage of the data is made accessible for the recipient to retrieve the data.

[0051] So, providing 150 the processed / unprocessed first and the second data comprises providing the processed / unprocessed first and / or the second data for the communication with an external device separate from the vehicle.

[0052] In practice, the processed / unprocessed first and second data, e.g., may be used by an ECU (e.g., a telematics control unit, TCU) of the vehicle and the processed / unprocessed first and second data is provided to the ECU via a controller area network (CAN) of the vehicle.

[0053] Further details are now laid out in more detail below with reference to Figs. 2 and 3.

[0054] Fig. 2 shows an exemplary use case of the approach. For this use case, a certain system model is assumed which is described in more detail below.

[0055] As can be seen from Fig. 2, multiple entities may be involved in use cases. Depending on the scenario, multiple instances of the same entity may occur.

[0056] Exemplary entities:

[0057] Vehicle: Generally, the in-vehicle architecture encompasses several entities, including Electronic Control Units (ECUs), sensors, actuators, zone controllers, High-Performance Computers (HPCs), among others.

[0058] Device:

[0059] A device refers to any wired or wireless device connected with the vehicle, such as mobile phones or wireless keys.

[0060] Road user / traffic participant: Road users / traffic participants encompass additional vehicles or pedestrians actively participating / interacting or communicating with the vehicle in the immediate traffic environment.

[0061] Service Provider:

[0062] Services can include fog or edge nodes, cloud backends, and third-party service providers.

[0063] The system model may distinguish between 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. Examples or the system levels or entities are as follows:

[0064] ECU, HPC (System level):

[0065] On ECU or HPC-level, e.g., a single ECU may receive (first and second) data from (directly or indirectly) connected sensors and actuators. It is proposed to treat an HPC equal to an ECU but with higher computation power. On the system level, data may not leave the ECU or the vehicle.

[0066] In-Vehicle Architecture (System level): The in-vehicle architecture may comprise a multitude of ECUs, Sensors, Actuators, Zone Controllers, HPCs, etc. On in-vehicle-architecture level, it is assumed that data is transferred amongst the different components inside the vehicle, but data does not leave the vehicle itself.

[0067] Vehicle-2-Device (Vehicle-2-X):

[0068] Vehicle-2-Device refers to the (wireless) connection of any device with the vehicle. It is assumed that the device is affiliated with the owner / driver / passenger of the car. Examples are mobile phones and wireless keys.

[0069] Vehicle-2-Roaduser (Vehicle-2 -X):

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

[0071] Vehicle-2-Service (Vehicle-2-X):

[0072] 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, e.g., to a (commercial) provider. The owner of the car might have an agreement I contract with the service provider. Services as commercial entities do not need to have their privacy protected.

[0073] In Fig. 2 the different entities and the different levels of the system model are depicted. A vehicle (e.g., an ego-vehicle applying the proposed approach) and a road user (e.g., another vehicle) are shown comprising multiple internal components (e.g., 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), and / or with wireless devices, such as keys or mobile phones (Vehicle-2-Device).

[0074] Also, a certain trust model may be assumed in applications.

[0075] Exemplary trust model:

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

[0077] Untrusted party:

[0078] A data owner / provider (e.g., a user of the vehicle) does not trust this kind of entity that will be responsible for processing / using the first and / or second data to be outsourced. As a consequence, whenever possible privacy requirements should be technically enforced if an un-trusted party is involved.

[0079] Semi-trusted party:

[0080] 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.

[0081] Trusted party:

[0082] The data owner / provider trusts the entity which will be charged of enabling the processing of their data (first and / or second data) while protecting their private / sensitive data. For example, because more valuable assets are at stake which overrule privacy concerns. In the following, some examples for trust models in context of the proposed disclosure are described in more detail with reference to different services, entities, and / or equipment:

[0083] • 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.

[0084] • 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.

[0085] • Third Party Services: These entities are classified as semi-trusted 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.

[0086] • Road Users / traffic participants: Road users / traffic participants 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.

[0087] As well, a certain data classification and a certain communication model which may include different communication types / modes may be assumed:

[0088] Exemplary communication types:

[0089] IN-IN (Level: ECU-2-ECU): Data 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). IN-OUT (Level: Vehicle-2-X (Sending)): 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.

[0090] OUT-IN (Level: 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 vehicle, as well as V2X information warning about an impending collision, thus requiring a braking maneuver.

[0091] IN-OUT-IN (Level: 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.

[0092] OUT-IN-OUT (Level: 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.

[0093] The first and second data may include data which allows direct or indirect identification. In context of the present disclosure, direct identification and in direct identification may be understood as follows:

[0094] Direct identification:

[0095] 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, one can identify the ensuing private data elements including in this group: (1 ) 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.

[0096] Indirect identification:

[0097] Indirect access may involve situations where privacy risks arise from apparently innocuous or non-sensitive data. Even if the data does not contain explicit personal information, sophisticated analysis or correlation techniques can indirectly identify individuals or their behavior. For instance, one can pinpoint the private data elements encompassed within this group:

[0098] (1 ) Vehicle material information: Almost all services offered to users need mechanical information. Several ECUs are injected to send the minimum information on the state of the vehicle material. The most important data that raise privacy risks are engine information (i.e., speed, acceleration, and gear shift, etc.), steering wheel position, media & infotainment, brakes information, feel information, etc. Therefore, by accumulating this data over the course of time, a malicious entity can deduce the users’ driving behavior.

[0099] (2) Location information: CAV components provide accurate vehicle location information, which reveals personal information about the location of the individuals who are using the vehicle. Some ECUs (e.g., GPS) provide private data such as starting position, geolocation, direction, and time. From this data, malicious entities can deduce specific sensitive data (e.g., a user’s home, office, and history of itineraries).

[0100] (3) CAV Applications: CAVs have interfaces to third-party systems such as Apple Car Play, Android Auto, or other services. They also support an interface between mobile phone applications and the vehicle. In this situation, the data concerned are users’ contacts, call logs, payment information, etc. Thus, an adversary can record private calls or steal payment information.

[0101] Now, further details should be described below with reference to Fig. 3 which schematically shows an exemplary in-vehicle architecture and a cloud for the proposed approach.

[0102] In particular, Fig. 3 relates to a generic use case to describe the functionality of the privacy manager.

[0103] In the present example, e.g., a user is operating a vehicle which has access to a (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 is not critical in terms of privacy. Thus, the main objective of the PM is to protect personal or sensitive data for other communication modes, e.g., Vehicle-2-X communication.

[0104] The PM provides a coordinated mechanism to apply PETs (based on the information on privacy and / or application-specific requirements). 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. 3 depicts an abstracted view of the vehicle’s architecture. It is assumed that the PM and applications are running in an high-performance computing platform (HPC).

[0105] 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 libraries which serve two purposes: Application of PETs and computation on raw data as sketched below.

[0106] The libraries may cover the application of PETs. To this end, the libraries may implement or include cryptographic primitives for the application of PETs, e.g., attribute-based encryption, multiparty computation, secret sharing, and / or the like.

[0107] One idea of the application of PETs within or by the privacy manager is that the privacy manager can manage and handle cryptographic keys, and thus the applications (e.g., the first and the second application) do not need to manage the cryptographic keys or has access to them. In this way, a higher level of privacy can be achieved.

[0108] As well, the libraries may include one or more libraries used for the computation on raw data. Such libraries may be provided by the applications.

[0109] One idea of the computation on sensitive (e.g., raw data) within the privacy manager is to separate the computation on sensitive data from the respective application (e.g., first and / or second application). For example, an application for in-cabin sleep detection might use in-cabin sensors such as camera images or cabin sensing radar. Since computation on the raw data of those sensors might allow to infer other data or information as well, e.g., if the driver is drunk, has used drugs or suffers from a disease, it might be desired to keep such information secret from the application. The proposed approach (the libraries separated from the application) allows that the computation / processing on sensitive, e.g., the raw camera data is separated from the application and only the (application-specific) result (driver awake or driver sleeping) is provided to the application. In this way, the release of non-application-specific information may be avoided for more privacy.

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

[0111] So, the first and / or the second data may be processed or provided according to predefined (different) modes. The modes may include the following modes:

[0112] Direct Access:

[0113] 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).

[0114] PET application:

[0115] The application communicates with the PM over an API (application programming interface) 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, attribute-based, 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 (INOUT), where e. g., access to certain sensitive data is limited to legitimate parties.

[0116] Computation from raw data:

[0117] The (first and / or second) 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. 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).

[0118] Combination

[0119] 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.

[0120] So, the information on the privacy and / or application-specific requirements, e.g., indicates which type party / entity (trusted, un-trusted, semi-trusted), the class of the first and / or the second data, and / or which information is technically required. Then, the privacy manager may select one or more of the above modes for processing or providing the first and / or the second data for the first and / or second application. In case of different technical and privacy requirements, different modes may be selected.

[0121] In this way, the first and the second data may be tailored such that they fulfill privacy but also technical requirements. In doing so, the privacy (of users) as well as the functionality of applications of the vehicle (e.g., autonomous driving, cabin monitoring, etc.) may be centrally ensured on a per-application basis.

[0122] The skilled person having benefit from the present disclosure will appreciate that the explained models and data classes as well as the suggested use cases are only examples of a plurality of embodiments. In particular, the proposed approach may be also applied to other applications, tasks (e.g., perception, motion, communication), models, hardware / architecture, data classes as well as for different data. Also, the proposed approach may be applied in different vehicles. So, the term “vehicle / s” is to be interpreted broadly in context of the present disclosure. Vehicles according to the present disclosure may include any kind of vehicle, including various ground vehicles (e.g., car, truck, bus, motorcycle, and / or the like), various watercrafts (e.g., boat), various aircrafts (e.g., planes, helicopters), and / or a combination thereof (e.g., amphibious vehicle).

[0123] It is noted that the proposed approach may be at least partly implemented as a computer program and / or computer implemented method. So, steps and / or features of described embodiments may be implemented in a computer program which when it is executed by a computer or any kind of programmable hardware causes the computer or hardware to execute one or more steps or parts of the proposed approach.

[0124] Features and aspects described in connection with the method may be analogously implemented in an apparatus according to the proposed approach.

[0125] Fig. 4 shows a block diagram schematically illustrating an embodiment of such an apparatus 400. The apparatus comprises one or more interfaces 410 for communication and a data processing circuit 420 configured to execute the proposed method.

[0126] In embodiments, the one or more interfaces 410 may comprise wired and / or wireless interfaces for transmitting and / or receiving communication signals in connection with the execution of the proposed concept. In practice, the interfaces, e.g., comprise pins, wires, antennas, and / or the like. As well, the interfaces may comprise means for (analog and / or digital) signal or data processing in connection with the communication, e.g., filters, samples, analog-to-digital converters, signal acquisition and / or reconstruction means as well as signal amplifiers, compressors and / or any encryption / decryption means. The data processing circuit 420 may correspond to or comprise any type of programable hardware. So, examples of the data processing circuit 420, e.g., comprise a memory, microcontroller, field programable gate arrays, one or more central, and / or graphical processing units. To execute the proposed method, the data processing circuit 420 may be configured to access or retrieve an appropriate computer program for the execution of the proposed method from a memory of the data processing circuit 420 or a separate memory which is communicatively coupled to the data processing circuit 420.

[0127] The apparatus, e.g., may be a component or may correspond to an ECU or HPC for a vehicle.

[0128] In the foregoing description, it can be seen that various features are grouped together in examples for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed examples require more features than are expressly recited in each claim. Rather, as the following claims reflect, subject matter may lie in less than all features of a single disclosed example. Thus, the following claims are hereby incorporated into the description, where each claim may stand on its own as a separate example. While each claim may stand on its own as a separate example, it is to be noted that, although a dependent claim may refer in the claims to a specific combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of each other dependent claim or a combination of each feature with other dependent or independent claims. Such combinations are proposed herein unless it is stated that a specific combination is not intended. Furthermore, it is intended to include also features of a claim to any other independent claim even if this claim is not directly made dependent to the independent claim.

[0129] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and / or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present embodiments. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that the embodiments be limited only by the claims and the equivalents thereof.

Claims

Patent claims1 . A method (100) for processing data of multiple applications of a vehicle by a central privacy manager, the method (100) comprising: obtaining (110) first data for a first application and second data for a second application; obtaining (120) information on privacy and / or application-specific requirements for the first and the second application; processing (130) the first data, if necessary, in accordance with the privacy and / or application-specific requirements for the first application; processing (140) the second data, if necessary, in accordance with the privacy and / or application-specific requirements for the second application; and providing (150) the processed / unprocessed first and second data for the first and the second application.

2. The method (100) of claim 1 , wherein the first and / or second data comprises sensor data and / or personal data of a user.

3. The method (100) of claim 1 or 2, wherein providing the processed / unprocessed first and the second data comprises providing the processed / unprocessed first and / or the second data for the communication with an external device separate from the vehicle.

4. The method (100) of any one of the preceding claims, wherein processing the first data comprises selecting one or more first privacy-enhancing technologies, PETs, based on the privacy and / orapplication-specific requirements for the first application, and applying the selected first PETs on the first data, and wherein processing the second data comprises selecting one or more second PETs based on the privacy and / or application-specific requirements for the second application, and applying the selected second PETs on the second data.

5. The method (100) of claim 4, wherein the first and second PETs include an anonymization algorithm, encryption algorithm, multi-party computation, and / or a perturbation algorithm.

6. The method (100) of any one of the preceding claims, wherein the first and / or the second application involve one or more electronic control units, ECUs, and / or one or more software applications.

7. The method (100) of any one of the preceding claims, wherein providing the processed / unprocessed first and second data comprises granting access to the first and / or second data to an external device separate from the vehicle.

8. The method (100) of any one of the preceding claims, wherein obtaining the first and the second data comprises receiving the first data from a first software application for the first application and receiving the second data from a second software application for the second application, and wherein the privacy manager is implemented in a third software application.

9. The method (100) of any one of the preceding claims, wherein the method (100) comprises applying one or more libraries for processing the first and second data, and wherein the privacy manager is privileged to obtain the processed first and second data from the libraries.

10. A computer program comprising instructions which, when the computer program is executed by a computer, cause the computer to carry out the method (100) of any one of the claims 1 to 9.11 . A computer-readable data carrier having stored thereon the computer program of claim 10.

12. An apparatus (400) comprising: one or more interfaces for communication; and a data processing circuit configured to execute the method (100) of any one of the claims 1 to 9.

13. A high-performance computer, HPC, for a vehicle, the HPC comprising the apparatus (400) of claim 12.

Images