A reference model as means for security of ...

A reference model as means for security of Automotive Cyber Systems Focus on Car-2-X Communication Jasmin Brückmann

Prof. Dr.-Ing. Hans-Joachim Hof

Tobias Madl

Munich University of Applied Sciences MuSe - Munich IT Security Research Group Munich, Germany Email: [email protected]

Technical University of Ingolstadt INSicherheit - Ingolstadt Research Group Applied IT-Security Ingolstadt, Germany Email: [email protected]

Munich University of Applied Sciences MuSe - Munich IT Security Research Group Munich, Germany Email: [email protected]

Abstract— The increasing computerization of vehicles and the communication of these with other vehicles and the whole ecosystem allow a myriad of attacks on this so called Automotive Cyber System (ACS). This paper presents a reference model of an ACS as an instrument for a holistic security approach. Thereby not only parts of the system are considered, but the whole cyber system, whereby more efficient and effective security mechanisms can be realised, because if only one component is missed, the whole system could be vulnerable. Finally, the reference model is used to identify neuralgic points in the ACS that are critical for the security.

I. INTRODUCTION The term 'Cyber Physical System' (CPS) describes the integration of physical and computational processes and objects that interact in local or global connected information networks. [1] If the CPS is focusing on vehicles, especially cars, it's about 'Automotive Cyber Physical Systems' (ACPS). This includes bus-systems, assistance systems or autonomous driving. Most security approaches are focusing on small parts of the ACPS like bus-systems or the head unit. As against, the approach of this project is a holistic approach. We aren't looking on the ACPS only but on the whole 'Automotive Cyber System' (ACS). This includes the car itself, the connection with the infrastructure as well as the connection to 'Original Equipment Manufacturers' (OEMs) and external partners. The promise of a holistic approach is that it allows a better integration of domain security into an overall concept, increased resistance to attacks, as well as increased efficiency by synergy effects. The efficiency is increased, because a problem isn't treated in every domain separately, but for all together, so problems are bundled and just one solution is needed. 'Holistic' implies 'complete', whereof the effectiveness is increased, because blind spots could endanger the system. If only one component is insecure, the whole system could be vulnerable. The first step is modelling the system to be analysed by a reference model of the whole ACS. One advantage of a reference model is, that it visualise the considerably

construct inclusive the relations between the involved components, which is helpful to understand the complex system. It also helps to carve out the essential parts to avoid missing important components. On the basis of this model neuralgic points for system security could be identified. Neuralgic points are components with a high security risk. The knowledge of the systems high risk components help to secure the system architecture. E.g. it could reduce the attack surface of the neuralgic points. Another approach is to establish single point of controls to single neuralgic points or groups of neuralgic points to enforce security policies, to log access etc. II. COMPARABLE CPS/ACS MODELS As mentioned, there are many domain specific examinations of automotive cyber physical systems so far, but less holistic approaches of the whole automotive cyber system. One method to value the security of a cyber physical system is 'aspect-oriented modelling' (AOM). Aspectoriented attack modelling has the goal to evaluate a system under attack. [2] Reference [2] exercises the AOM on automotives. Therefore some known attacks are diagrammed with AOM. It's a good approach to assess the security of a CPS, but therefore already known attacks are needed and our goal is to prevent unknown either. Additionally [2] is only looking on parts of an automotive and not the whole system. The standardisation 'AUTOSAR' has the goal to develop a reference architecture for ECUs in vehicles. It provides a reference model which contains middleware software components, the application layer and the Run Time Environment of vehicles. Thereby it's focused on the vehicle itself and not the environment inclusive OEM and external partners. [3] The reference [4] already uses a holistic approach to consider the cyber security of vehicles, including the entire life cycle from development, over production, operations and

secure provisioning services. They present a reference model from a car comparable to the reference model in this research project, but without the environment vironment with infrastructures, OEMs and external partners or the data flows. flows The introduced models are all approaches to view the automotive cyber physical systems but not any observes the whole ACS as intended with our reference model. III. REFERENCE MODEL The reference model of the ACS is split in two diagrams: a component diagram and a data flow diagram. The component diagram shows 'components' and 'entities'. A component can contain further components or entities. The data flow diagram views the data flows of the whole ACS in 3 layers. Layer 1 presents an overview with the top components without hout interior components or entities. The second layer presents the data flows between interior components and the third between entities (entity-entity (entity and entity-component). Figure 1 describes the symbols used in the component and the data flow diagrams. Symbol 1: A component Symbol 2: An entity Symbol 3: Shows which bus-type type is used for communication. The description of the arrow describes which data are transferred. Symbol 4: Indicates a two-directional directional data flow and the input and output data. Symbol 5: Describes a one-way way data flow and the transferred data.

Fig. 2. Automotive Cyber System

Fig. 1 Legend of the ACS

Symbol 6: Represents a gateway from internal to external communication. The identification names the external transmission medium. A. Overview of the automotive utomotivec cybersy stem reference model The ACS consists of 4 main components as shown in Figure 2: The component ‘Car’ or vehicle is the central component and contains processing units, a communication system, the in-vehicle vehicle infotainment unit, sensors and actuators. For an in depth description ption of this components, see [5 [5]. They are out of the scope for this his paper. This paper focuses on the car car-to-x communication and the involved components. For the sake of completeness all missing parts of the reference model can be found in the appendix.

Fig. 3. Component diagram - 'Original Equipment Manufacturer M & External Partner'

The second component, which is considered more in detail in this paper, is the ‘Original Equipment Manufacturers (OEM) and External Partner’ component, which is providing management services like software updates, navigation information (maps, traffic updates etc.), etc.) or entertainment features likee checking mails or music. The third component, ‘Infrastructure’ component represents the environment of the car like street lights, road signs or other vehicles which are directly communicating with the car to share status information. A part of the infrastructure are so called ‘Location-based based Services’ (LBSs), which are described later (p. C. Vehicle to Infrastructure). The infrastructure is talking with the 'OEM and external partner' component,, too, to exchange status Information. The last component, ‘Communication Infrastructure’ Infrastructu

Fig. 4. Data flow diagram - External Partners

component facilitates the communication between the main components. It consists of cellular networks like LTE or UMTS and local WiFi-Hotspots Hotspots. For the purpose of a clear presentation this component is out of the scope of this paper. All missing diagrams are added in the appendix. Below, the different vehicle vehicle-to-x communications are described. B. Vehicle to OEMs and External Partners Figure 3 shows the inferior components and entities from the OEMs and external partners. The 'Management Services' component provides important services to guaranty the functionality and security of the car. For example, OEMs have to provide software softwareand firmware-updates. updates. Emerging attacks require security updates for vehicle software. Important updates should be

Fig. 5. Data flow diagram - Original Equipment Manufacturer

distributed over-the-air air (FOTA and SOTA), because a fast dissemination of updates is important especially to close possible vulnerabilities in software. FOTA and SOTA are a good example of the holistic approach. We don't look only on the start by the OEM or the end at the he car. We are looking on both and additionally on the step between, the communication infrastructure. Every part is important because every interface could be vulnerable. ‘OEM M services’ are additionally features that the OEM offers. For example, an OEM could serve personalized offers like a reminder for service attendances. It can also provide traffic information or sponsored offers from external partners. The FAS (‘Fahrzeugassistenssysteme’ sistenssysteme’, driving assistance system) and HAF (‘Hochauomatisiertes ‘Hochauomatisiertes Fahren’, high autonomous driving)systems systems from the car are also getting information from the OEM. These two services require statistic/usage data from the car. To improve their servicess or line card the OEM needs the data for their own propose, too. These are important to learn what the customer wants or needs. Therefore information has to be collected, anonymised, evaluated, and stored by the 'data analysis platform'. As example for external ternal partners, the companies Google and ADAC ('Allgemeiner Allgemeiner Deutscher Automobil Club', Club general german automobile association) are selected. The components of the external partners are a choice of services

they are providing. Both offer ‘Mobility Services’ like information about the current traffic situation. As well as the OEMs, the external xternal partner are collection statistic and usage data from the vehicle and the passengers with a ‘Data Analysis Platform’. To secure external communication communication, all the traffic from the outside to the inside and back should pass a ‘Security Platform’ with security procedures such as a firewall firewalls, to gain a single point of access,, where the whole traffic can be observed easier. Google has for example the additional components ‘Gmail’, ‘Maps’ and ‘Search’. By ‘Gmail’, passenge passengers can retrieve and send their mails. ‘Maps’ provides maps and navigation information. With ‘Search’ the passengers can use for example the Google search. ADAC has the extra services ‘Maintenance Control’ and ‘Insurance Adjustments’. Among other things, the ‘Maintenance Control’ monitors the maintenance status of the car and informs the driver if the car needs an inspection or mending. The ‘Insurance Adjustme Adjustment’ monitors the driving behaviour.. If the driver drives save and pays attention to the traffic regulations the insurance conditions could improve. Figure 4 shows the internal data flows from the OEM as well ass the external data with the external partners and the

car. The most communication takes place with the car. The data analysis platform receives statistics from the car such as driving hours, hardware, or software incidents. Traffic and location data can be used for statistics, too. Once the collected data is processed it can be used by the OEM- and management services for example to improve their services ices and enlarge their range of products. products

components such as search queries and map data. ADAC has a data analysis platform, too, for the same ppurpose as the OEMs and Google, as well as the mobility services. The ‘Maintenance Control’ component monitors if the car should come to an inspection in the near future and informs the driver as needed. In order er to analyze the driving behaviour, the ‘Insurance Adjustment’ component needs the driving data from the car.

The OEM Services receive traffic and SOS requests and send the corresponding responses. For traffic requests and extended information, they need the location data from the car. Additionally they communicating ing with the HAF/FAS systems of the car, for example advanced traffic information. This includes redirection because of current accidents or disruptions or automatic searching for a parking site.

Both external partners are in contact with the OEM to share special or sponsored offers for the customers like bargains for the OEM’s customers omers ffrom the external partner, so the whole data exchanges are showed to represent the whole system view.

The Management Services receive car related information to support upport the driver ideally for example in case of incidents or hardware and software issues. Additionally, software and firmware updates are provided by the management services, named as management data in the data flow diagram. Service information about the th car and the OEM are also delivered by the management services.

C. Vehicle to Infrastructure The component 'Infrastructure' represents the environment of the car. This includes traffic control devices like street lights, road signs or speed measurements just as stores or other establishments which are directly communicating with the car and in order to that a part of the holistic system view, too.

For the holistic approach not only the internal data flows of the OEM are described, but also the external communication directly to the car and the external partners.

RSU stands for 'Road Site Unit' and summarizes all traffic control devices while ‘Location Based Services’ (LBS) “are IT services for providing information that has been created, compiled, selected, or filtered taking into consideration the current locations of the users or those of other persons or mobile objects.” [[6, xi]. LBS are provided for example by local stores, OEMs or third party companies to supply current offers, promotions, location based advertising or information about the current location like restaurants, points of interests or service stations in the immediate vicinity. [6]

Figure 5. presents the data flows from the external partners Google and ADAC.. The Google ‘Search’ component receives search requests and answers with search results. For navigation purposes, the map and navigation data can be retrieved by the car from the ‘Maps’ component. Gmail grants the passengers access to their mail accounts and provides sending and receiving mails among other things. The ‘Mobility Services’ are used to request current information about the traffic situation. All components co are sending statistics and usage data to the data analysis platform to be processed and used to improve the services. The inin and outgoing traffic to and from the car is related to the service

Fig. 6. Component diagram - Infrastructure

The RSU as well as the LBS are exchanging their information over LTE, WIFI or UMTS with the car. Thereby the RSU is directly talking with the car’s OBU (Onboard Unit). [7]

Fig. 7. Data flow diagram – Infrastructure

The car and the RSU are exchanging status information, for example the current status of the street light or the speed of the car. The infrastructure is talking to the OEMs and external partners, too. It can send status information about the traffic or speed signs receive commands to readjust the tempo limit e.g. Local stores or establishments can provide LBS to the car. For example, sponsored or special offers or promotions. promotion They can send their range of products or personalized advertisement. They can sendd status information for big data analysis to the OEMs and external partners or receive status information or additional offers e.g. D. Vehicle to vehicle communication For the communication between vehicles, a special WiFi protocol is used,, beside other communication procedures. procedures Vehicles are exchanging status information about themselves and the environment. For example, if a car registers an accident or special condition such as black ice or

Fig. 8. Data flow diagram - Car to Car

aquaplaning, it sends it to all vehicles in a range of influence. [7]] The reference model diagrams are containing just one car, because every component is just represented once and the cars are identically. E. In-Vehicle Vehicle Infotainment Unit The ‘In-Vehicle Vehicle Infotainment Unit’ is the central component of the infotainment infotainment-system. It combines all features for the passengers to be entertained and to grant their needs. It shouldn’t contain any functions to affect the safety or security of the car. It provides interfaces to connect different devices like smartphones or tablets with the car. These are often USB, Bluetooth and WiFi. The entertainment functions are accessed over applications (Apps). For example, there could be apps to listen to music from om a connected phone or via internet or to show traffic updates or maps. The ‘In-Vehicle Vehicle Infotainment (IVI) Unit’ transfers data on a separate bus, the MOST. The MOST (Media Oriented System Transport) bus system is used to transport

IV.

HIGH-RISK COMPONENTS

To consider the security re requirements for the ACS in the next step neuralgic points should be identified on the basis of the reference model. These points are components with a high security risk. The cooperative cooperative-paper [5] examines the high-risk risk components of the intra intra-vehicle communication while this paper focuses on risks from the communication between the car and outer components.

Fig. 9. Component diagram - In-vehicle vehicle Infotainment Unit

multimedia data such as audio, video, navigation or telecommunication. [8] The IVI unit is mostly communicating with outer components such as the OEM, external partners or external devices. Additionally it communicates over the can bus with the ‘Infotainment ECU’ in the component ‘Processing Units’ which is described in the cooperative-paper [55]

As presented in this paper, the gateways and interfaces like WiFi or Bluetooth are the junctures between the inside and the outside of the car. All incoming and outgoing traffic has to pass this entrance. If an attacker tries to get into the vehicles inner cyber system system, he first has to pass these gateways. In the worst case an attacker can get the full control of the car, for example over the current speed or the handling. Because of the severe consequences, the gateways and interfaces are high risk compon components (or neuralgic points). The in-vehicle-infotainment infotainment unit uses the interfaces WiFi, USB and Bluetooth to provide their services and facilitates the direct connection with external devices. These devices es could contain malicious software, which could be transferred to the car onn this way. It also needs a direct internet access for the app services like mail, google search or different ferent music applications. This includes the risk of getting viruses or other malicious software software, for example from downloading manipulated music, opening a malicious mail appendix or visiting a dubious website. Because of the direct connection over the can bus with the inner cyber system and the contemplated external interfaces, the in-vehicleinfotainment system is a high risk component with many areas to attack. Other neuralgic points are the software and firmware of the car. To avoid the abuse of known vulnerabilities, both should be always up to date te. The process of over the air updating is critical, too. Unauthorized persons could manipulate an upcoming or running updat update, to infiltrate malicious code. The communication between the vehicle and the infrastructure, as well as between cars, is another neuralgic point,, because the communication leads directly inside the inner communication system systems. Exchanged information could be eavesdropped or manipulated. In the worst case malicious code could be planted to contaminate the inner cyber system and open backdoors for thee attacker, that could allow the take-over of the system. Another possibility for attackers is to masquerade themselves as a communication ppartner to steal information or to channel malware. Thereby it makes no odds if the communication partner is a relatively slight street sign,, a location based service or another car.

Fig. 10. Data flow diagram - In-vehicle vehicle Infotainment Unit U

The last high risk components are tthe OEMs and the external partners. Both are providing data and software for a large amount of vehicles. If an attacker breaks in an OEM's or external partner'ss backend backend, malicious code could be disseminated to a great range of vehicles, while they assume e.g. that it´s a matter tter of update relying upon the OEM or the external partner.

The existence of these high risk components has some consequences for the overall security architecture. A small choice should be mentioned: The gateways have to be secured to hold attackers off for example with firewalls, intrusion detection or prevention systems. Received packages by the car should be authenticated and authorized, as well as the communication partners. In every external communication, every communication partner should be sure, who they are talking to. Every entity, that can communicate with the car, should be secured, to avoid illegal take-overs. It should be possible to check the integrity and origin of software/firmware updates as well as every external data, for example by checksums and signatures. OEMs and external partners should have high security standards, too. Insecure providers of services should be avoided, if possible. V.

CONCLUSION

This paper presents a reference model for Automotive cyber systems. The reference model eases the identification of neuralgic points that are of uttermost importance for a holistic security architecture of Automotive Cyber Systems. The paper lists a collection of high-level high risk components that are candidates for neuralgic points. Future work will focus on these neuralgic points to elaborate the overall holistic security architecture as well as appropriate security controls for ACS. VI. [1]

[2]

[3]

[4]

[5]

[6] [7] [8]

REFERENCES

Geisberger, Eva, and Manfred Broy, eds. agendaCPS: Integrierte Forschungsagenda Cyber-Physical Systems. Vol. 1. Springer-Verlag, 2012 Wasicek, Armin, Patricia Derler, and Edward A. Lee. "Aspectoriented modeling of attacks in automotive cyber-physical systems." Design Automation Conference (DAC), 2014 51st ACM/EDAC/IEEE. IEEE, 2014. Navet, Nicolas, and Françoise Simonot-Lion. In-vehicle communication networks-a historical perspective and review. University of Luxembourg, 2013. Ebert, Christof and Metzker, Eduard, Cyber Security for the Automotive Industry, Practical experiences on the application of Cyber Security, Technicle Article, Vector Informatik GmbH, September 2016 Madl, Tobias, Reference Architecture for the design of secure Automotive Cyber Systems, University of Applied Science Munich, 2017 Küpper, Axel. Location-based services: fundamentals and operation. John Wiley & Sons, 2005. Hager, Markus. Funksysteme, Protokolle und Anwendungen der Carto-X-Kommunikation, Technische Universität Ilmenau, 2013 Schmid, Markus. Automotive Bus Systems. Automotive Applications, Atmel, 2004.

Appendix A 'Car' component

Fig. 11. Data flow diagram - Car

Fig. 12. Component diagram - Car

Appendix B 'Communication Infrastructure' component

Fig. 13. Data flow diagram - Communication Infrastructure

Fig. 14. Component diagram - Communication Infrastructure