1

Automotive Cybersecurity: Towards the Next Generation Architecture

Michele Scalas∗, Giorgio Giacinto∗ ∗Department of Electrical and Electronic Engineering, University of Cagliari, Italy

{michele.scalas, giacinto}@diee.unica.it

Abstract

The automotive industry is experiencing a serious transformation due to a digitalization process and the new paradigm of Mobility-as-a-Service. V2X, autonomous driving and electrical vehicles are some of the keywords involved, and they are causing cybersecurity issues. The next generation vehicle is going to be a very complex cyber-physical system, whose design must consider several information technology notions, so much so that the OEMs themselves are more and more similar to IT companies. The ”old” automotive architecture relied on a single closed network, with no external communications, so cybersecurity had low priority; modern vehicles are going to be always connected indeed, which means the attack surface will be much bigger. The result is the need for a paradigm shift towards a secure-by-design approach. In this paper an overview of the current standards used to create the in-vehicle network will be provided. A major focus is pointed on the CAN network, backbone and most used protocol in current automotive architectures. Then, the attack scenarios will be described, along with the attackers goals and strategies. Finally, the requirements and the solutions, including the most prominents projects, will be presented.

Index Terms

Cybersecurity, Mobility, Automotive, Cyber-physical systems, CAN

1 INTRODUCTION

HE automotive industry is experiencing a serious transformation due to a digitalization process in many of its aspects and the new mobility models. A recent research initiative from IHS Markit (2017) outlines the

trend, stating that:

’By 2040, vehicle miles travelled (VMT) will have grown to an all-time high of around 11 billion miles per year (a 65 percent increase since 2017) in China, Europe, India and the United States –the key markets examined for the study– and will keep growing. At the same time, sales growth of new light-duty vehicles will slow substantially.’

T

2

The main factor for this phenomenon is the concept of Mobility-as-a-Service (MaaS), which means car sharing services are going to be as frequent as car individual ownership. In this sense, the keywords that will contribute to this new model are ’connected cars’, ’autonomous driving’ and ’electrical vehicles’. A connected car goes beyond the intuitive meaning of being connected to the Internet through cellular networks or having a navigation system through GPS, in fact future connected vehicles will adopt a V2X (Vehicle-to-X) paradigm. This term refers to the possibility of the car to communicate and exchange data with other vehicles (V2V, Vehicle-to-Vehicle), with a generic infrastructure (V2I) or with pedestrians (V2P). The typical application of these models are smart cities, with the aim of optimizing the traffic management, sending alerts in case of incidents, etc. As regards autonomous driving, it consists in expanding the current Advanced Driver Assistance Systems (ADASs), such as lane keeping and braking assistants, in order to obtain a fully autonomous driverless car. The Society of Automotive Engineers (SAE) provides in fact six possible levels of autonomy, from level 0, with no assistance, to level 5, where the presence of the driver inside the car is not needed at all. Finally, electric vehicles require lesser parts than those equipped with Internal Combustion Engines (ICEs) and are easier to maintain, which allow new players to enter the market.

All these innovations have a common denominator: information technology. Current top end vehicles have about 100 million lines of code, up to 150 Electronic Control Units (ECUs) and more than 5 km copper wires (Timo van Roermund 2015), which means cars are becoming very complex software-based IT systems. This fact marks a major shift in the industry: the ”mechanical” world of original equipment manufacturers (OEMs) is converging towards that of IT companies. In this context there are consequently new challenges for the industry, such as cybersecurity. The electronic architecture of the vehicle has been designed and standardized over the years for a ”closed” system, in which all the data of the ECUs stay in the internal network. The above new services require instead that data spread across multiple networks, as can be seen in Figure 1; there is therefore a bigger attack surface, i.e. new possibilities to be vulnerable to the attackers. Hence, automotive OEMs need to reinvent the car architecture with a secure-by-design approach.

One last remark to complete this introductory overview can be the description of modern vehicles as cyber-physical systems (CPSs), which Minerva, Biru, and Rotondi (2015) define as:

’A system of collaborating computational elements controlling physical entities. It is when the mechanical and electrical systems (e.g., sensors and communication tools) embedded in products and materials are networked using software components. They use shared knowledge and information from processes to independently control logistics and production systems. [...] In contrast to traditional embedded systems, the CPS is a network of interacting appliances with physical inputs and outputs instead of standalone devices.’

This definition reminds that, in terms of security, there is not only the cyber-related aspect but also the physical-related one. As an example, autonomous driving implies heavily interacting with the real world environment and facing the challenge of guaranteeing resilience of the sensing and actuation devices. Therefore, cyber-physical security analyses the issues of adversaries that can act both in the cyber- and physical space in order to mislead or disrupt the normal working condition of the whole system, with the final goal of producing failures and hazards in the physical space. Automotive security then involves taking into account also the specific issues of a CPS, as can be seen in the work from Wang, Ye, and Xu (2010); however, in this paper the main focus will be attacks that are carried out in the cyber-space.

3

Fig. 1. The vehicle ecosystem.1

Paper structure. In this paper, Section 2 firstly lists the constraints in a car design, then describes the principal standards for the internal network and the related security vulnerabilities. Section 3 presents the various goals of the cyberattacks against vehicles, while Section 4 makes an overview of recent attacks. Section 5 illustrates the proposed solutions for new architectures and Section 6 finally makes concluding remarks.

2 AUTOMOTIVE NETWORKS This Section starts with a list of the constraints in the automotive industry in order to better understand the design choices for the protocols.

2.1 Constraints Although usual IT security concepts can be used to design car electronics, there are some specific constraints to consider both in hardware and software, as summarized by Studnia et al. (2013) and Pike et al. (2017): Part Cost The automotive industry is extremely sensitive to part cost, so using more expensive hardware

might be not viable. Limited Hardware The typical ECUs for cars are embedded systems with strong hardware limitations, that

is with low computing power and memory. This means some security solutions like cryptography might be not fully implemented. However, there is a transitioning towards higher-performance processors.

Timing Several ECUs must perform tasks with fixed real-time constraints, which are often safety-critical. Therefore, any security measure must not impact these tasks.

Autonomy Since the driver must be focused on driving, the car should be autonomous as much as possible when protection mechanisms take place.

Physical Constraints The ECUs are exposed and must resist demanding conditions like low/high temperatures, shocks, vibrations, electromagnetic interferences etc.

Life-cycle The life-cycle of a car is much longer than that of common consumer electronics, so the need for durable hardware and easy-to-update software (especially security-related one).

1FromadraftpaperbyUNECEon’RecommendationsforCyberSecurity’(availableonhttps://wiki.unece.org/pages/viewpage.action?pageId=56591532)

4

Compatibility Due to the cost sensitivity, new components might have to integrate with legacy components. Size and Weight Size and weight of the components might have a serious impact. The typical example of

this is the design of the internal network: a bus topology is preferable compared to a star one because of the much lower number of wires to employ.

Standardization For the OEMs it’s not always possible to embrace innovations and detach from industry standards in the supply chain because of the higher costs.

Supplier Integration To defend intellectual property, suppliers often provide (software) components without source code, therefore any modification with the aim of improving security can be more difficult.

2.2 Main Standards Current vehicles mix different types of networks to let the dozens of ECUs communicate. As can be seen in Figure 2, in a modern car there are different sub-networks for each domain, i.e. for the different functionalities. The main standards, typically suited for a specific domain and the related requirements, are: LIN, MOST, FlexRay and CAN; the latter represents the backbone of the entire network, so it’s explanatory to understand the critical points in automotive cybersecurity. It’s worth noting that, due to the transitioning phase in the industry, the topology and the standards are going to change, as will be better illustrated in Section 5; for example, Automotive Ethernet is already one of the new protocols employed and will be introduced below.

Fig. 2. Main domains in a modern car. (ENISA 2016)

First of all, SAE makes a classification of the communication protocols based on bandwidth, latency and reliability:

5

• Class A: it demands up to 10 Kb/s and a latency of 50÷150 ms; its usage is for low-end, non-emission diagnostic, general purpose communication;

• Class B: it supports data rates between 10 Kb/s and 125 Kb/s; it is used for non-diagnostic, non-critical communications, typically event-driven or periodic;

• Class C: it supports data rates between 125 Kb/s and 1 Mb/s; it is employed in critical and real-time control systems, such as engine, brake or traction control;

• Class D: it supports data rates over 1 Mb/s and it is mostly suited for multimedia data. Following the survey by Huo et al. (2015), a brief description of the various protocols can be the following:

LIN It stands for Local Interconnect Network, this is a class A low cost network for the ”body” domain, i.e. the area of comfort functions such as climate control, door lock, rain sensor, etc. LIN can be implemented with a single wire, it can reach as high as 20Kbit/s and it is commonly used as a sub bus for CAN and FlexRay.

MOST The Media Oriented System Transport is a class D protocol for the infotainment domain, so for radio, GPS navigation, etc. It reaches up to shared 150 Mb/s through polymer optical fiber and in one of its variants provides a physical layer to implement Ethernet.

FlexRay It’s a class D protocol with a data rate up to 10 Mb/s through twisted pair wire. It is suited for safety-critical systems that need predictability, fault tolerance and real-time behaviour, in fact it is typically employed to implement ’x-by-wire’ functions, that is the electronic control of steering, pedals, belts and similar.

Automotive Ethernet Although its adoption is still limited, Ethernet has a key role for next generation automotive networks. It is a widespread standard for the common IT uses and its high bandwidth is a desirable characteristic for modern vehicles; however, as it is, is not suited for automotive and that’s why we talk about ’Automotive Ethernet’: in the past few years, among the various proposals, BroadR-Reach by Broadcom emerged and now its scheme has been standardized by IEEE (802.3bp and 802.3bw) and other variants are under development also by ISO. The standard is currently guided by the One-Pair Ether-Net (OPEN) alliance. The main difference compared to standard Ethernet is the use of a unique unshielded twisted pair, which let the cost, size and weight significantly decrease, without sacrificing the bandwidth (100 or 1000 Mb/s).

CAN The Controller Area Network is the most used protocol for the in-vehicle network. It was released in 1986 but several variants and standards have been developed over the years. For simplicity, there is a low speed CAN that reaches up to 125 Kb/s while the high speed version reaches up to 1 Mb/s; the first one belongs to class B and it’s suited for the body domain, the other one is a class C used in ’powertrain’ (engine or transmission control) and ’chassis’ (suspension, steering or braking) domain. The CAN network is implemented with twisted pair wires and an essential aspect is the network topology, which is a bus line, as can be seen in the schematic of Figure 3.

Fig. 3. Traditional CAN bus topology

6

This Figure represents a traditional CAN bus topology; actually, in this transition phase current vehicles have a slightly different setting, where a Domain Controller (DC) manages the related domain subnetwork (each one with its appropriate protocol), but the main idea is still the same: the CAN bus is the backbone and all the data spread across the entire network, in broadcast mode.

Before moving on to the description of the vulnerabilities caused by these designs, it’s useful to introduce an important standard for diagnostics: OBD. It stands for On-Board Diagnostics and it consists in a port, mandatory for US and European vehicles, that enables self-diagnostic capabilities in order to detect and signal to the car owner or to a technician the presence of malfunctions in a specific component. It gives direct access to the CAN bus, then causing a serious security threat, as will be described in Section 4; moreover, anyone can buy cheap dongles for the OBD port, extract its data and read them for example with a smartphone app.

2.3 Vulnerabilities The constraints described in Section 2.1, such as the need to reduce the cost and the size impact of the network, together with a context in which the in-vehicle data was not exposed to external networks, caused the presence in the (CAN) backbone of the following design vulnerabilities (Liu et al. 2017): Broadcast transmission Because of the bus topology, the messages between the ECUs spread across the

entire network, causing a serious threat: accessing one part of the network (for example the OBD port) implies the possibility to send messages to the entire network or being able to eavesdrop on these communications.

No authentication There is no authentication that indicates the source of the frames, which means it’s possible to send fake messages from every part of the network.

No encryption The messages can be easily analysed or recorded in order to figure out their function. ID-based priority scheme Each CAN frame contains an identifier and a priority field; the transmission of

a high priority frame causes the lower priority ones to back off, which enables Denial of Service (DoS) attacks.

3 ATTACK GOALS In this Section, different motivations that attract the attackers are described. Taking the works by Studnia et al. (2013) and IET (2014) as references, these are the possible attack goals: Vehicle theft This is the obvious and widespread reason to attack a vehicle. Vehicle enhancement This refers to software modifications realized especially by the owner of the car. The

goal might be to lower the mileage of the vehicle, tune the engine settings or install unofficial software in the infotainment.

Extortion This can be achieved for example through a ransomware-like strategy, i.e. blocking the victim’s car until a fee is paid.

Intellectual challenge The attack is conducted to demonstrate hacking ability. Intellectual property theft This refers to elicitation of the source code for industrial espionage. Data theft This is an increasingly important goal, consequence of the new paradigm of connected cars. There

are different types of data to steal, such as: • License plates, insurance and tax data; • Location traces; • Data coming from the connection with a smartphone, such as contacts, text messages, social media

data, banking records, etc. The combination of these data might allow the attacker to discover the victim’s habits and points of interest, exposing him to burglary or similar attacks.

7

4 ATTACK SCENARIOS In this Section, an overview of attack techniques and examples is provided; following the work by Liu et al. (2017), the typical attack scheme, visible in Figure 4, includes an initial phase in which a physical (e.g. OBD) or wireless (e.g. Bluetooth) car interface is exploited in order to access the in-vehicle network. The most common interface to access it is OBD, but there are several works that start their attacks from different entry points: Checkoway et al. (2011) succeeded in sending arbitrary CAN frames through a modified WMA audio file burned onto a CD. The work by Mazloom et al. (2016) showed instead some vulnerabilities in the MirrorLink standard that allow to control the internal CAN bus through a USB connected smartphone. Rouf et al. (2010) analysed the potential vulnerabilities in the Tire Pressure Monitoring System (TPMS), while Garcia et al. (2016) found out that two widespread schemes for keyless entry systems present vulnerabilities that allow to clone the remote control, thus gaining unauthorized access to the vehicle. Moreover, the attacks concern not only ”light vehicles”, Burakova et al. (2016) for example focused on a truck.

Once the interface is chosen, then the following methodologies are used to prepare and implement the attack:

Frame sniffing Leveraging the broadcast transmission and the lack of cryptography in the network, the attacker can eavesdrop on the frames and discover their function. It’s the typical first step to prepare the attack. An example of CAN frames sniffing and analysis is the work by Valasek and Miller (2013).

Frame falsifying Once the details of the CAN frames are known, it’s possible to create fake messages with false data in order to mislead the ECUs and/or the driver, e.g. with wrong speedometer reading.

Frame injection The fake frames, set with the appropriate ID, are injected in the CAN bus to target a specific node; this is possible because of the lack of authentication. Two examples can be the works by Woo, Jo, and Lee (2015) and by Miller and Valasek (2015), both through remote access, so they leverage the services enabled by in-vehicle cellular networks or the smartphone connectivity. In the first case the authors developed an Android app masquerading as a self-diagnostic tool, a common app type that together with an OBD scan device let the user obtain real-time data from the vehicle. With this malicious app, they redirected the extracted CAN traffic to a remote server and were also able to send CAN frames into the bus. The second -and very notorious- attack regards the exploitation of the 2014 Jeep Cherokee infotainment system, which contains the ability to communicate over Sprint’s cellular network in order to offer in-car Wifi, real-time traffic updates and other services. This remote attack allowed to control some cyber-physical mechanisms such as steering and braking. The discovery of the vulnerabilities in the infotainment caused a 1.4 million vehicle recall by FCA, so this is a very illustrative example of the impact that a security flaw can produce.

Replay attack In this case the attacker sends a recorded series of valid frames in the bus at the appropriate time, so he can repeat the car opening, start the engine, turn the lights on, etc. Koscher et al. (2010) implemented a replay attack in a real car scenario.

DoS attack As anticipated in Section 2.3, flooding the network with the highest priority frames prevents the ECUs from regularly sending their messages, therefore causing a denial of service. An example of this attack is the work by Palanca et al. (2017).

8

Fig. 4. General attack procedure. (Liu et al. 2017)

5 SECURITY COUNTERMEASURES This Section firstly aims to summarize the basic security principles to consider when designing car electronics and the related technology solutions. Then, it focuses on the major projects for new architectures.

5.1 Requirements Starting from the security requirements, a typical pattern to help developing secure architectures is the so-called ’CIA triad’, i.e. three conditions that should be guaranteed as far as possible, they are: confidentiality, integrity, availability. Taking into account the current reference backbone -the CAN bus- the previous Sections demonstrated that none of these aspects are inherently guaranteed. Bearing in mind these concepts and taking a cue from the work by ACEA (2017), the proposed countermeasures and some of the related implementations in the literature are the following: Dedicated HW To supply the scarcity of computing power of the ECUs and satisfy the real-time constraints,

it may be necessary to integrate hardware platforms specifically designed for security functions. This approach has been pursued for example in the EVITA and HIS project and it is referred as Hardware Security Module (HSM) or Security Hardware Extension (SHE).

Cryptography Encryption can help ensuring confidentiality and integrity. It’s worth noting that implementing cryptography is not trivial, since the low computing power may prevent the OEMs from using strong algorithms, which means cryptography might be even counter-productive. The guidelines recommend state-of-the-art standards, taking care of key management and possibly using dedicated

9

hardware. There are several works about cryptography, for example Zelle, Krauß, and Schmidt (2017) investigated whether the well-known TLS protocol is applicable to invehicle networks.

Authentication Since different ECUs interact with each other, it’s fundamental to know the sender of every incoming message. Two recent works that integrate authentication are those by Mundhenk et al. (2017) and Van Bulck, Muhlberg,¨ and Piessens (2017).

Access control Every component must be authorized in order to gain access to other parts. The guidelines suggest to adopt the principle of least privilege, i.e. a policy whereby each user (each ECU in this case) should have the lowest level of privileges which still permits to perform its tasks.

Isolation/Slicing This hardening measure aims at preventing the chance for an attacker to damage the entire network. This can be achieved for example isolating the driving systems from the other networks (e.g. the infotainment), or through a central gateway that employs access control mechanisms.

Intrusion detection Intrusion Detection Systems (IDSs) monitor the activities in the network searching for malicious or anomalous actions. Some examples in literature are the works by Song, H. R. Kim, and H. K. Kim (2016) and by M.-J. Kang and J.-W. Kang (2016), which uses deep neural networks.

Secure updates The Over-The-Air (OTA) updates are on the one hand a risk that increases the attack surface, on the other they are an opportunity to easily fix the discovered vulnerabilities (besides adding new services). Some recent works to secure the updates but also V2X communications are those by Dorri et al. (2017) and Steger et al. (2018), both taking advantage of blockchain.

Incident response and recovery It is necessary to ensure an appropriate response to incidents, limit the impact of the failures and be always able to restore the standard vehicle functionality.

All the above aspects should be fulfilled in a Security Development Life-cycle (SDL) perspective, with data protection and privacy as priority. Testing and information sharing among industry actors are recommended.

5.2 Main Projects In the past ten years several projects started, aiming to integrate the ideas of the previous Section in an organic way; a map of these initiatives can be seen in Figure 5, thanks to a detailed paper of good practices and recommendations made by ENISA (2016).

Fig. 5. Safety and security initiatives inside and outside of the automotive domains. (ENISA (ibid.))

10

Among these projects, SAE J30612 , finalized in 2016, provides guidance on vehicle cybersecurity development process, ranging from the basic principles to the design tools. However, a new international standard, the ISO/SAE 21434, is under development; its goal is to (a) describe the requirements for risk management (b) define a framework that manages these requirements, without indicating specific technologies, rather giving a reference, useful also for legal aspects.

Moreover, the implementation of these guidelines and the transition towards a new in-vehicle network architecture is currently guided by some projects like AUTOSAR3. This is a partnership born in 2003 between several stakeholders, ranging from the OEMs to the semi-conductors companies, which aims to improve the management of the E/E architectures through reuse and exchangeability of software modules; concretely, it standardizes the software architecture of the ECUs. It’s still an active project, now also focused on autonomous driving and V2X applications, and it covers different functionalities, from cybersecurity to diagnostic, safety, communication. AUTOSAR also supports different software standards, such as GENIVI4, another important alliance aiming to develop open software solutions for In-Vehicle Infotainment (IVI) systems.

The main message of all these projects is the new focus on security, which must start from the beginning of the development process. 5.3 Next Generation Architecture To complete the picture of the solutions to manage the huge change the automotive industry is experiencing, in this Section a brief overview of a potential next generation vehicle network will be provided. Two keywords can be chosen to portray the new architecture, respectively on the software and hardware side: service orientation and Ethernet.

As regards the first one, Service Oriented Architecture (SOA) means that each component provides a service and sends the data only to the subscribers, in contrast to the traditional broadcast system. In a certain way, it’s a further enhancement of the current domain-based scheme and an implementation of the idea of isolation introduced in Section 5.1. This architecture in fact includes a central gateway that manages the internal network and provides an interface to the external ones. A representation of this can be seen in Figure 6, where the gateway is called Central Communication Server (CCS). This Figure has been done by Traub, Maier, and Barbehon (2017) from BMW, who designed an architecture according to which the ECUs are classified on the basis of the performance, security and safety requirements; it’s a scheme for a seamless communication between protocols (CAN, FlexRay, etc.) and a physical and logical separation of the services.

2https://www.sae.org/standards/content/j3061201601/3https://www.autosar.org4https://www.genivi.org

11

Fig. 6. Central communication server for a scalable E/E architecture. (Traub, Maier, and Barbehon (ibid.))

Moving onto the hardware side, these innovations encourage and are at the same time encouraged by the Ethernet protocol, which seems the first candidate to become the backbone of the future networks, as can be seen in Figure 7.

6 CONCLUSION To sum up, in this paper we deduced how the rapid digitalization process within the automotive industry, where the OEMs are converging towards IT companies and the vehicles are becoming ”smartphones on wheels”, came up against serious cybersecurity issues, due to security flaws inherited by an original design where the in-vehicle network didn’t interact with the external world. By contrast, the new revolution of Mobility-as-a-Service causes the vehicle to be hyper-connected and consequently much more exposed to cyber threats.

In this transition phase, we observed the effort in developing more and more complex platforms in a safety-critical context with strict requirements such as the limited hardware and the real-time constraints. For these reasons the research projects are trying to leverage IT methodologies and solutions from other domains and tailor them for the automotive one.

As a final remark, it’s worth recalling that, since the car is a very complex cyber-physical system, automotive security also implies cyber-physical security (out of the scope of this paper), pre-eminently important for autonomous driving and V2X communications, which deserves a separate study.

12

Fig. 7. Ethernet backbone. (Keysight Technologies (2017))

ACKNOWLEDGMENT The authors thank Abinsula srl for the useful discussions on the mechanisms of the automotive industry and its trends. REFERENCES ACEA (2017). Principles of Automobile Cybersecurity. Tech. rep. Burakova, Yelizaveta et al. (2016). “Truck Hacking: An Experimental Analysis of the SAE J1939 Standard”.

In: Proceedings of the 10th USENIX Conference on Offensive Technologies. Vol. 10. USENIX Association, pp. 211–220.

Checkoway, Stephen et al. (2011). “Comprehensive Experimental Analyses of Automotive Attack Surfaces”. In: Proceedings of the 20th USENIX conference on Security. San Francisco, CA: USENIX Association, pp. 6–6.

Dorri, Ali et al. (2017). “BlockChain: A Distributed Solution to Automotive Security and Privacy”. In: IEEE Communications Magazine 55.12, pp. 119–125.

ENISA (2016). Cyber Security and Resilience of smart cars. Tech. rep. Garcia, Flavio D et al. (2016). “Lock It and Still Lose It - On the (In)Security of Automotive Remote Keyless

Entry Systems”. In: Proceedings of the 25th USENIX Security Symposium. Huo, Yinjia et al. (2015). “A survey of in-vehicle communications: Requirements, solutions and

opportunities in IoT”. In: IEEE World Forum on Internet of Things, WF-IoT 2015 - Proceedings, pp. 132–137.

IET (2014). Automotive Cyber Security : An IET/KTN Thought Leadership Review of risk perspectives for connected vehicles. Tech. rep.

IHS Markit (2017). The Future of Cars 2040: Miles Traveled Will Soar While Sales of New Vehicles Will Slow, New IHS Markit Study Says. URL: http://news.ihsmarkit.com/press-release/energy-power-media/future-cars-2040-miles-traveledwill-soar-while-sales-new-vehicles-.

13

Kang, Min-Joo and Je-Won Kang (2016). “Intrusion Detection System Using Deep Neural Network for In-Vehicle Network Security”. In: Plos One 11.6.

Keysight Technologies (2017). Automotive Ethernet Solutions. Tech. rep. Koscher, Karl et al. (2010). “Experimental security analysis of a modern automobile”. In: Proceedings -

IEEE Symposium on Security and Privacy, pp. 447–462. Liu, Jiajia et al. (2017). “In-vehicle network attacks and countermeasures: Challenges and future directions”.

In: IEEE Network 31.5, pp. 50–58. Mazloom, Sahar et al. (2016). “A Security Analysis of an In-Vehicle Infotainment and App Platform”. In:

Proceedings of the 10th USENIX Conference on Offensive Technologies. USENIX Association, pp. 232–243.

Miller, Charlie and Chris Valasek (2015). “Remote Exploitation of an Unaltered Passenger Vehicle”. In: Defcon 23 2015, pp. 1–91.

Minerva, Roberto, Abyi Biru, and Domenico Rotondi (2015). “Towards a Definition of IoT”. In: pp. 1–86. Mundhenk, Philipp et al. (2017). “Security in Automotive Networks: Lightweight Authentication and Authorization”. In:

22.2. Palanca, Andrea et al. (2017). “A stealth, selective, link-layer denial-of-service attack against automotive

networks”. In: Lecture Notes in Computer Science. Springer Verlag, pp. 185–206. Pike, Lee et al. (2017). “Secure Automotive Software: The Next Steps”. In: IEEE Software 34.3, pp. 49–55. Rouf, Ishtiaq et al. (2010). “Security and Privacy Vulnerabilities of In-Car Wireless Networks : A Tire

Pressure Monitoring System Case Study”. In: Proceedings of the 19th USENIX Conference on Security. USENIX Association, pp. 21–21.

Song, Hyun Min, Ha Rang Kim, and Huy Kang Kim (2016). “Intrusion detection system based on the analysis of time intervals of CAN messages for in-vehicle network”. In: International Conference on Information Networking. Vol. 2016March, pp. 63–68.

Steger, Marco et al. (2018). “Secure Wireless Automotive Software Updates Using Blockchains: A Proof of Concept”. In: Advanced Microsystems for Automotive Applications 2017. Lecture Notes in Mobility. Springer, Cham, pp. 137–149.

Studnia, Ivan et al. (2013). “Survey on security threats and protection mechanisms in embedded automotive networks”. In: Proceedings of the International Conference on Dependable Systems and Networks.

Timo van Roermund (2015). Secure Connected Cars For a Smarter World. Tech. rep. NXP. Traub, Matthias, Alexander Maier, and Kai L. Barbehon (2017). “Future Automotive Architecture and the

Impact of IT Trends”. In: IEEE Software 34.3, pp. 27–32. Valasek, Chris and Charlie Miller (2013). “Adventures in Automotive Networks and Control Units”. In: Defcon 21. Van Bulck, Jo, Jan Tobias Muhlberg, and Frank Piessens (2017). “VulCAN: Efficient Component

Authentication and Software¨ Isolation for Automotive Control Networks”. In: Proceedings of the 33rd Annual Computer Security Applications Conference, pp. 225–237.

Wang, Eric Ke, Yunming Ye, and Xiaofei Xu (2010). “Security Issues and Challenges for Cyber Physical System”. In: Woo, Samuel, Hyo Jin Jo, and Dong Hoon Lee (2015). “A Practical Wireless Attack on the Connected Car

and Security Protocol for In-Vehicle CAN”. In: IEEE Transactions on Intelligent Transportation Systems 16.2, pp. 993–1006.

Zelle, Daniel, Christoph Krauß, and Karsten Schmidt (2017). “On Using TLS to Secure In-Vehicle Networks”. In: Proceedings of the 12th International Conference on Availability, Reliability and Security. ACM, 67:1–67:10.

14

Tutti gli scritti pubblicati dal CSSII sono sotto la responsabilità esclusiva dei singoli autori