text: www.enisa.europa.eu European Union Agency For Network And Information Security

text: Cyber Security and Resilience of smart cars

text: December 2016

text: December 2016

text: December 2016

text: December 2016

text: December 2016

text: December 2016

text: December 2016

text: See http://www.forbes.com/sites/leoking/2015/02/23/14-year-old-hacks-connected-cars-with-pocket-money/ Anthony Foxx, Secretary, U S Department of Transportation and Mary Barra, the chairwomen and CEO of General Motors Company, stress the importance of these issues in a keynote talk at the Billington Cyber summit 2016 https://www.youtube.com/watch?v=F-sPC2qHkq8 See http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ See http://www.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive- 2540957.html See http://arstechnica.com/cars/2016/08/hackers-use-arduino-to-unlock-100-million-volkswagens/ The affected company producing around 10 million vehicles a year. See http://www.bbc.com/news/technology-37426442

text: December 2016

text: Identification of 6. Workshop experts

text: Conclusions and 2. Desktop recommendations research

text: Collection of experts and 4. Analysis stakeholders point of view

text: Figure 1: Methodology used to carry out the study

text: December 2016

text: See http://ec.europa.eu/transport/themes/its/c-its_en.htm See http://ec.europa.eu/transport/index_en.htm See https://resilience.enisa.europa.eu/carsec-expert-group See https://ec.europa.eu/digital-single-market/ecall-time-saved-lives-saved See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ENG See http://eur-lex.europa.eu/legal-content/en/ALL/?uri=CELEX:31995L0046 See https://ec.europa.eu/digital-single-market/en/news/network-and-information-security-directive-co-legislatorsagree-first-eu-wide-legislation See https://ec.europa.eu/digital-single-market/alliance-internet-things-innovation-aioti See http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11822

text: December 2016

text: December 2016

text: December 2016

text: See also https://english.eu2016.nl/binaries/eu2016-en/documents/publications/2016/04/14/declaration-ofamsterdam/2016-04-08-declaration-of-amsterdam-final-format-3.pdf The notion of V2X encompasses Vehicle-to-infrastructure (V2I), Vehicle-to-vehicle (V2V) and Vehicle-to-pedestrian (V2P) use cases.

text: December 2016

text: Figure 2: Automation level of vehicles

text: December 2016

text: Figure 3 : High-level architecture of a smart car

text: December 2016

text: Figure 4 : Smart cars assets

text: December 2016

text: Such as: powertrain, brake, suspension, airbag See http://www.automotive-eetimes.com/news/arm-architecture-leads-automotive-market-semicast-finds Embedded in the processor itself ISO 11898-1:2015 Road vehicles -- Controller area network (CAN) -- Part 1: Data link layer and physical signalling http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=63648 Most notably in Miller, C., & Valasek, C. (2013). Adventures in automotive networks and control units. DEF CON, 21, 260-264. See http://standards.ieee.org/findstds/standard/802.3bw-2015.html ISO 17458-1:2013 Road vehicles -- FlexRay communications system -- Part 1: General information and use case definition http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59804

text: December 2016

text: LIN Network for Vehicle Applications http://standards.sae.org/j2602/1_201211/ Radio Frequency protocols include among others S-WAVE Smart Wave, Zigbee, Bluetooth low energy, Wi-Fi, IEEE 802.15.4,Z wave. RF modules are also commonly used in proprietary protocols, such as a car key fobs.

text: December 2016

text: Depending on the vehicle architecture, these services can be can be spread differently, for instance as part of the Telematics Gateway ECU (next section).

text: December 2016

text: Figure 5 : An example of external interfaces of a smart car

text: As already mentioned in section 2.1, we take into account V2X interfaces even if V2X is not addressed as a use case in this report.

text: December 2016

text: 35 The state-of-the-art also suggests possible alternatives, such as DSA or WiMAX for V2I communication , or CEN-DSRC (5.8 GHz) and ETSI-DSRC (5.9 GHz) for Electronic Tolling.

text: Such as: 2G, 3G, 4G See Lu, N., Cheng, N., Zhang, N., Shen, X., & Mark, J. W. (2014). Connected vehicles: Solutions and challenges. IEEE internet of things journal, 1(4), 289-299. For example Mirrorlink, CarPlay or Automotive Link See http://www.surewise.com/car-warranty/articles/how-wearable-tech-influences-smart-cars/ See https://openconnectivity.org/press-releases/open-connectivity-foundation-announces-automotive-project See Msadaa, I. C., Cataldi, P., & Filali, F. (2010, July). A comparative study between 802.11 p and mobile WiMAXbased V2I communication networks. In 2010 Fourth International Conference on Next Generation Mobile Applications, Services and Technologies (pp. 186-191). IEEE. See http://ec.europa.eu/transport/themes/its/c-its_en.htm

text: December 2016

text: See for example https://www.wired.com/2016/08/hackers-fool-tesla-ss-autopilot-hide-spoof-obstacles/ and https://www.wired.com/2016/06/teslas-autopilot-first-deadly-crash/

text: December 2016

text: While these functionalities are out of scope of this study, we still need to consider them as potential entry points for an attacker.

text: December 2016

text: Figure 6: Interviews: Main threats as perceived by interviewees

text: ENISA. (2015). Cyber security and resilience of intelligent public transport: good practices and recommendations. McCarthy, C., Harnett, K., & Carter, A. (2014). Characterization of potential security threats in modern automobiles: A composite modeling approach (No. DOT HS 812).

text: December 2016

text: Table 1 - List of threats and assets affected

text: CATEGORY THREAT VARIANTS AND DETAILS ASSETS AFFECTED

text: This may typically consist in several scenarios : tampering with the ECUs or TCUs (to recover keys or access physical debug interfaces); using the device electro-magnetic emanations or power usage to leak Side channel, fault information (side-channel); use light, power or other ECUs and sensors injection, means to alter the device behavior and ultimately (privileged debug Physical glitching, access gain access to protected data (glitch, fault injection). interfaces of the ECUs, threats to HW debug Physical threats arise from a well-identified attack causing a cascading ports… vector (physical manipulation of devices). They impact on all assets) might lead to various types of risks, including the

text: categories described hereafter as Nefarious Activity/Abuse or

text: Eavesdropping/Interception/Hijacking.

text: Mostly IP-sensitive

text: firmware of the ECUs

text: This may typically concern administration errors in Information and sensors, as well as back-end services or errors when storing data leakage or sharing private data intended for diagnostic in garages, for example. transmitted over

text: Erroneous use or Unintentional damages (accidental) may result from

text: ECUs and sensors,

text: administration of insufficiently trained personnel (for example when causing a cascading devices and using diagnostic equipment), or from an incorrect impact on all assets systems OTA update pushed by the backend services.

text: Unintentional damages may cascade from ill-defined Unintentional Using information trust relationships: for example, trusting a thirddamages from an unreliable party cloud provider with poor data protection, or All assets (accidental) source failing to notify a Tier developer that the data they will store is sensitive.

text: Unintentional Unintentional damages (accidental) may result from

text: ECUs and sensors,

text: change of data in insufficiently trained personnel (for example when causing a cascading an information using diagnostic equipment), or from an incorrect impact on all assets system OTA update pushed by the backend services.

text: Unintentional damages (accidental) may result from insufficiently trained personnel (for administration, Inadequate design design, operation…) causing for example and planning or All assets incompatibilities between components, or lack of lack of adaption adaptation to the changing threat landscape (the use of vulnerable cryptography is an example of this).

text: A Network outage (for example from the ISP) may result in a denial of service for sensitive operations, such as OTA fixes for critical bugs or vulnerabilities. This is also true for internal networks failures. Disasters and More generally, any design relying too much on Network outage All assets Outages connectivity exposes the vehicle to potential issues in case of outages. Vehicles should be designed to offer a usable degraded mode of operation in case of outage. See also Failures/ Malfunctions

text: December 2016

text: Sensitive data stored by

text: cloud service providers

text: Loss of Sensitive data may be lost due to attacks or (these data do not

text: information in the accidents when stored by third-party cloud service appear on the asset list,

text: cloud providers but may typically be

text: related to infotainment control)

text: The (integrity of) sensitive data may be lost due to IT

text: Loss of (integrity components wear and tear, causing potential

text: of) sensitive cascading issues (in case of a key alteration, for All assets

text: information example) Damage/ Loss (IT Assets) See also Failures/ Malfunctions

text: Sensitive data may be lost or compromised due to Private data Damage caused physical damages in cases of a traffic accident or transmitted over by a third party theft. subnetworks

text: User data (traffic- or travel-related services, Private data Loss from DRM audio/video entertainment…) may be deleted due to transmitted over conflicts DRM issues subnetworks

text: Private or sensitive data (such as payment Private data Information information, driving habits…) may be leaked when transmitted over leakage the car is sold to another user. subnetworks

text: Failures /

text: malfunctions of See Damage/ Loss (IT Assets) - Loss of (integrity of) - (parts of) devices sensitive information

text: or systems

text: A failure of power supply has obvious safety issues

text: besides security issues. However, security causes Failures or additional constraints. Typically, some security disruptions of the functions (for example anti-tampering mechanisms) All assets power/main should rely on separate and trusted power sources, supply to avoid both accidental security failures and Failures/ potentially exploitable flaws for an attacker Malfunctions

text: The presence of software bugs is a basis for potential

text: exploitable vulnerabilities. The lack of a software

text: Software bugs measure for the Mean-Time-Between-Failure also All assets

text: implies that software bugs are more likely to happen

text: than Hardware failures over the lifetime of a car.

text: Failures or

text: disruptions of See Disasters and Outages - Network outage All assets communication

text: Interception of

text: information / See physical threats. All assets Interfering Eavesdropping radiations / Interception/

text: Hijacking Sensitive data Replay of If internal networks are not sufficiently protected transmitted on messages against replay, potential attackers have an easy

text: December 2016

text: access to a wide range of dangerous commands, such as steering, braking…

text: A large set of interfaces means that, assuming a poor protection of the session, there are many incentives for an attacker to impersonate a distant user: - Impersonating an app store, or service provider, may lead to financial abuse; - Impersonating backend systems may help the attacker in downloading a rogue Man in the firmware on the vehicle; middle/ session All assets - Impersonating another vehicle on a V2V hijacking session may trigger dangerous behaviours; - Impersonating a legitimate keyfob may lead to theft; - etc. The same notion can also be applied to internal network, for example to perform a MitM on the CAN bus .

text: Information on car networks can be obtained in Network Wireless External many ways (looking for successive MSISDN numbers reconnaissance communication for OTA updates, looking for vulnerable devices on and information 43 networks or Shodan , war driving for vulnerable protocols such gathering subnetworks as ZigBee or Wi-Fi…)

text: The liability of the driver being possibly engaged in accidents/assurance/professional contexts, there is Data related to Repudiation of an incentive to compromise data related to the car powertrain control, actions usage such as driving habits or localization. This is Chassis control or simply the extension of existing fraud schemes, for infotainment control example on tachographs.

text: The denial of service is not only to be understood as a particular form of network outage. A denial of service may also be triggered on internal network by Denial of service flooding a CAN bus, or by provoking faults on an ECU All assets via a malicious payload. The potential impact of such an attack depends on the targeted ECU, but may Nefarious lead to unexpected behaviours from driving systems Activity/ Abuse Changing the firmware of a component, or Manipulation of otherwise altering its configuration data, is an hardware & essential step of many attacks. The risk is software, All assets emphasized when there are no measures to protect Manipulation of the authenticity of critical data or components, such information as a secure boot.

text: See https://www.blackhat.com/us-16/briefings.html#canspy-a-platform-for-auditing-can-devices https://www.shodan.io/

text: December 2016

text: Manipulation of hardware also allows to perform a man-in-the-middle (for example, cutting the CAN bus or isolating a given ECU )

text: The type of threat attracting the most attention of All assets Unauthorised the media is the case where a remote attacker can access to take the control of an ECU (or impersonate an ECU information on an internal subnetwork) and take the control of a system/network car by sending driving-related commands (steering, braking…).

text: While information leak may be accidental (See All assets Compromising Damage/ Loss (IT Assets) - Information leakage), confidential there are also incentives for attackers to deliberately information compromise private data or sensitive data such as keys

text: The simplest case of identity fraud is the cloning of a All assets keyfob. This may, however, be completed by other cases, such as fraud, for example if a user wants their car to display another identity when Identity fraud communicating: - with road infrastructures such as toll systems; - with manufacturer backend .

text: A user may try to access unauthorized functions for All assets various reasons: they might want to circumvent DRMs on applications or media, or get an unauthorized access to features (geo-fencing, digital Unauthorised use

text: tachograph… See Eavesdropping/ Interception/

text: of administration

text: Hijacking - Repudiation of actions), or they might

text: of devices & simply want to tune the vehicle for comfort or systems, performance purpose. Unauthorised use of software, Outside vehicles, manufacturers may also be Unauthorised confronted with garages using unauthorized or installation of unlicensed professional tools and software. software This threat also includes the notion of cloning, for example when an attacker copies the firmware of an existing device, in order to commercialize it without authorization.

text: A disgruntled employee (backend services, garage) Abuse of may use their authorizations to perform malicious authorizations, actions. Abuse of A slightly different scenario would be for an All assets information infotainment application to abuse its authorizations leakage (for example, to mine private data or perform surveillance activities)

text: See https://www.blackhat.com/docs/us-16/materials/us-16-Demay-CANSPY-A-Platorm-For-Auditing-CAN-Deviceswp.pdf See a recent example : https://www.wired.com/2016/03/thousands-trucks-buses-ambulances-may-open-hackers/ See http://www.securityfocus.com/archive/1/538862?_sm_au_=icV3HHS2mMF57J6r

text: December 2016

text: The impact of such threats is enhanced in cases where the system itself leaks data due to a poor security design.

text: The integration of infotainment and mobile ecosystems may cause an increase of potential malicious software introduced by the user. Malicious software may provide a first step for attackers in a multi-step attack, to get in driving systems via the infotainment subnetwork. Malicious Malicious software may also be a first step to gain software, access to professional systems (e.g. garages or All assets Malicious backend), thus potentially gaining a privileged access software activity on a large set of vehicles. It has to be noted that these ties to the mobile and PC ecosystems also means that attackers may recycle well-known attacks paths (generic linux/android/windows) to eventually affect smart cars .

text: All external interfaces may be subject to code Remote activity injection, which may ultimately result in code

text: All assets

text: (execution) execution in case of insufficient component robustness.

text: Some security researchers consider smart car attacks as similar to Advanced Persistent Threats, or advanced enterprise threats, especially because the Advanced attackers have to move “laterally into multiple Persistent - systems”. This risk is also relevant for infrastructures All assets Threats (APT) (backend systems, or even V2X infrastructures). Such attacks typically use several types of methods and entry points, therefore can be a mix of every other threat described in this table.

text: It was notably the main point of http://blog.crysys.hu/2015/10/hacking-cars-in-the-style-of-stuxnet/ See https://blog.lookout.com/blog/2015/08/07/hacking-a-tesla/ Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance components - September 2012 - Version 3.1 Revision 4 Common Methodology for Information Technology Security Evaluation - Evaluation methodology - September 2012 - Version 3.1 Revision 4

text: December 2016

text: December 2016

text: Table 2 : Sample attacks

text: THREATS ATTACK LESSONS LEARNED

text: Network Remote attack (see section 3.4.1 for more details on how Lack of communication protection reconnaissance and this kind of attack can be performed) (from the point of view of the

text: information 51 discovery and the lack of First introduced in 2011 , remote attacks on cars (via gathering, internet) have been widely exposed in the press due to the authentication); lack of Unauthorised access 52 Identification, authentication and work of Charlie Miller and Chris Valasek . This type of attack to information typically included attempts to craft messages on the CAN authorization for actions accessible system/network bus to change the behaviour of the vehicle. remotely.

text: Network Lack of communication protection

text: Remote attack (see section 3.4.1 for more details on how

text: reconnaissance and (from the point of view of the

text: this kind of attack can be performed)

text: information discovery and the lack of gathering, In a variation of previous attacks, the access gained remotely authentication); lack of can be used for other purposes, for example force the geo- Unauthorised access Identification, authentication and fencing of the vehicle, as exposed in a more recent example to information authorization for actions accessible of remote attack system/network remotely.

text: Lack of libraries authentication and

text: Persistent vehicle alteration (see section 3.4.2 for more

text: Malicious software, lack of integrity checks for external

text: details on how this kind of attack can be performed)

text: Unauthorised components on diagnostic installation of Researchers compromised libraries used by garages to equipment control diagnostic tools, in order to allow the installation of software Use of vulnerable cryptographic malicious firmware on cars functions

text: Direct CAN access is easier than

text: many manufacturers might think. Manipulation of details on how this kind of attack can be performed) Lack of protections in the CAN hardware, Man in the Researchers with a physical access to the vehicle performed protocol allow to perform a manmiddle, replay of a man-in-the-middle by inserting an unauthorized in-the-middle, even if timing messages component directly on the CAN bus, then proceeded to constraints makes the exploitation drop/alter/replay messages. non-trivial in practice

text: Theft (see section 3.4.3 for more details on how this kind of

text: Man in the middle,

text: attack can be performed)

text: Inadequate design Vulnerable (implementation of) and planning or lack Researchers recently presented a correlation-based attack cryptography of adaption on remote keyless entry systems concerning millions of cars (“most VW Group vehicles manufactured between 1995 and

text: See Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., ... & Kohno, T. (2011, August). Comprehensive Experimental Analyses of Automotive Attack Surfaces. In USENIX Security Symposium. For example : https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/, https://www.wired.com/2015/07/patch-chrysler-vehicle-now-wireless-hacking-technique/, https://www.wired.com/2016/08/jeep-hackers-return-high-speed-steering-acceleration-hacks/, and https://www.wired.com/2015/08/uber-hires-hackers-wirelessly-hijacked-jeep/ See for example http://jcarlosnorte.com/security/2016/03/06/hacking-tachographs-from-the-internets.html

text: December 2016

text: [2016]” ). In this case, the researchers claim that the attack could explain theft cases found in the wild. This follows a long history of attacks on keyless entry (including notably the RollJam attack) and start 5657 systems , all of which relying on cheap hardware and short exploitation time. Attacks exploiting vulnerable cryptography on these systems are not new, with examples as far as 2005 .

text: attack can be performed) Identification, authentication and

text: Unauthorised use of

text: Thefts have been shown to use, in the wild, administration authorization is needed for access

text: administration of

text: to privileged functions, especially equipment to defeat keyless entry and start systems .

text: devices & systems

text: These equipment were initially intended for locksmiths and for maintenance equipment. car dealers.

text: Surveillance (see section 3.4.4 for more details on how this

text: Surveillance is possible in practice

text: kind of attack can be performed)

text: Information leakage, for a mid-range attacker; interfaces Researchers devised an experimental setup to validate their Abuse of information (e.g. ITS interfaces) lack the cost analysis estimation of a surveillance attack performed leakage pseudonymity measures allowing by a mid-range attacker using dedicated hardware. The to mitigate the attack attack uses ITS communication interfaces .

text: See Garcia, F. D., Oswald, D., Kasper, T., & Pavlidès, P. (2016). Lock It and Still Lose It–On the (In) Security of Automotive Remote Keyless Entry Systems. In 25nd USENIX Security Symposium (USENIX Security 2016). USENIX Association (to appear, 2016). See https://www.wired.com/2015/08/hackers-tiny-device-unlocks-cars-opens-garages/ See Francillon, A., Danev, B., & Capkun, S. (2011, February). Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars. In NDSS. See https://www.wired.com/2016/03/study-finds-24-car-models-open-unlocking-ignition-hack/ See Bono, S., Green, M., Stubblefield, A., Juels, A., Rubin, A. D., & Szydlo, M. (2005, July). Security Analysis of a Cryptographically-Enabled RFID Device. In USENIX Security (Vol. 5, pp. 1-16). See http://fortune.com/2016/08/06/houston-car-hackers/ See https://www.blackhat.com/docs/eu-15/materials/eu-15-Petit-Self-Driving-And-Connected-Cars-Fooling- Sensors-And-Tracking-Drivers-wp2.pdf

text: December 2016

text: Table 3 : Attack scenario 1 - remote attack

text: TYPE OF DESCRIPTION ASSET AFFECTED ATTACK

text: In a first step,

text: This attack exploits vulnerabilities in external functional interfaces, related to

text: telematics or infotainment. Connected ECUs may be used in a variety of Remote, via 61 networks are functional uses, all of which can be an entry point for such attacks . functional targeted. interfaces The scenario could typically follow these steps: first identify a vulnerable car, Ultimately, all

text: then gain access to internal services (e.g. on a TCU), and eventually, from ECUs and the access gained onto the vehicle, obtain an access to vehicle systems. sensors may be

text: CRITICALITY LIKELIHOOD

text: Unlikely High

text: IO CASCADING EFFECTS STAKEHOLDERS INVOLVED

text: ENAR All stakeholders providing, or operating external interfaces (ISPs, SC Vehicle (safety) systems disruption may manufacturers, Tiers, aftermarket and app providers, cloud CK result in an accident, possibly involving other service providers). ECU manufacturers also concerned, since this TA vehicles. scenario exploits the lack of ECU self-protection.

text: AT RECOVERY TIME AND EFFORTS GOOD PRACTICES

text:  General good practices apply (Policy and standards, organizational measures)  In terms of security functions, Communication protection is Even if vulnerabilities may be fixed by an obviously needed to mitigate these attacks, and well as OTA update, and even if the vehicle does Identification, authentication and authorization for all actions not seem physically damaged, it is likely accessible remotely. These functions are supported by that a physical inspection will be needed 63

text: Cryptography, Security Audit, and software self-protection.

text: to ensure that safety is maintained.  Separation of telematics and infotainment traffic is recommended allowing specialized handling of packets regarding intrusion and malware detection.

text: CHALLENGES AND GAPS

text: Insecure design or development, Safety and security process integration.

text: December 2016

text: Figure 7 : Remote attacks threatening passengers’ safety

text: These steps are very similar to what is described in previous research, in particular Miller, C., & Valasek, C. (2014). A survey of remote automotive attack surfaces. Black Hat USA Alternatively (in the example of Miller/Valasek), the attacker discovers the TCU on Shodan because the carrier supports direct IP R. Ofir and O. Kapora. A remote attack on an aftermarket telematics service. http://argus-sec.com/blog/remoteattack-aftermarket-telematics-service, Jul. 2014. Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematic failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15). Alternatively (in the example of Miller/Valasek), the attacker may try to directly communicate with ECUs because it contains non-diversified SSH credentials (that may have been extracted by a previous physical attack on another vehicle).

text: December 2016

text: See Miller, C., & Valasek, C. (2014). A survey of remote automotive attack surfaces. Black Hat USA See https://www.youtube.com/watch?v=ryNtz1nxmO4 See Fernandes, E., Crispo, B., & Conti, M. (2013). Fm 99.9, radio virus: Exploiting fm radio broadcasts for malware deployment. IEEE Transactions on Information Forensics and Security, 8(6), 1027-1037. See Car Hacker’s Handbook by Craig Smith

text: December 2016

text: Table 4 : Attack scenario 2: persistent vehicle alteration

text: In the case of an alteration by the legitimate user, The primary targets are the OBD II

text: the scenario could consist in getting a direct ports from the Diagnostic and connection to car components, then trying to maintenance systems. In the case

text: persistently alter the behaviour of a given ECU. of an alteration by the user, assets

text: The objective may be for example vehicle tuning, related to the access control

text: bypass of the geo-fencing on a corporate vehicle … 74

text: functions of the ECUs and sensors

text: Local, via The user may also use diagnostic equipment, which are targeted. functional or may also be used by other categories of attackers, In the case of a garage attack, IP and

text: for example in a garage. The steps would then diagnostic Trade secrets, but also private data

text: consist in obtaining a legitimate or illegitimate

text: interfaces stored on ECUs and sensors, or

text: access to diagnostic equipment, then exploiting a 75

text: transiting on subnetworks .

text: vulnerability in the diagnostic equipment to persistently alter the behaviour of an ECU. In a In both cases, Powertrain control

text: garage context, such an attack may be related to and vehicle safety systems from

text: Chassis or body control may be hit

text: business intelligence as much as an attack on the vehicle itself indirectly

text: CRITICALITY LIKELIHOOD

text: IO Possible to Unlikely High

text: ENAR CASCADING EFFECTS STAKEHOLDERS INVOLVED SC

text: CK All stakeholders providing ECUs, diagnostic The immediate effect can range from a data TA equipment or aftermarket dongles (car leak to a disruption of vehicle systems. This AT manufacturers, Tiers, aftermarket providers). may result in an accident, possibly involving Garages are also concerned, since attacks other vehicles, while a data leak has less performed via diagnostic equipment are likely to critical consequence, but may result in brand use garages as an entry point. damage.

text: RECOVERY TIME AND GOOD PRACTICES EFFORTS

text:  General good practices apply (Policy and standards,

text: organizational measures) Even if vulnerabilities may be  In terms of security functions, Communication protection is fixed by an OTA update, and obviously needed to mitigate these attacks, as well as even if the vehicle appears to

text: Identification, authentication and authorization for all actions

text: be physically damaged, it is

text: accessible via diagnostic interfaces. Physical self-protection also

text: likely that a physical contributes to reduce the attack surface for local attacks (see inspection will be needed to 8.1.3.6 for details). ensure that safety is  These functions are supported by Cryptography, Security Audit, maintained.

text: and software self-protection.

text: CHALLENGES AND GAPS

text: Insecure design or development (especially for the access control to maintenance tools), safety and

text: security process integration

text: The assets primarily targeted are mostly related to access control, especially access to functions not intended for

text: users (fleet management, digital tachograph, geo-fencing...). Studies give example of privileged services than can be

text: December 2016

text: compromised because static keys were discovered by a memory dump (for example SSH keys). Other targeted assets

text: are the driving systems, especially in cases where the user tries to modify the performance of their vehicle. Vehicle

text: safety systems may also be at risk due to accidental side effects of the attack. Modified traffic on the CAN bus may for example trigger denials of service on the bus, or otherwise cause dangerous situations to arise on vehicle systems.

text: IP and Trade secrets may be targeted. In a context related to organized crime, the assets are more likely to be vehicle safety systems, driving systems or private data (especially payment data)

text: http://www.euro-controle-route.eu/site/en/info/tacograph/fraud/ For the example of digital tachographs see: https://www.tispol.org/content/2016/02/02/07/31/technology-usedtachograph-fraud-becoming-more-complex-and-sophisticated-0 See for example, http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-posram-scraper-malware.pdf See Miller, C., & Valasek, C. (2013). Adventures in automotive networks and control units. DEF CON, 21, 260-264 Adventures in Automotive Networks and Control Units, Valasek/Miller. The document highlights the fact that analyzing and crafting CAN packets is not an easy task. See Car Hacker’s Handbook by Craig Smith, which reminds that it requires to obtain, and then reverse-engineer a firmware, which is not trivial See for example Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematics failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15).

text: December 2016

text: Figure 8 : Persistent vehicle alteration scenarios

text: Table 5 : Attack scenario 3 - Theft

text: TYPE OF DESCRIPTION ASSET AFFECTED IO ATTACK

text: Body control domain and External ENAR

text: Several possible scenarios, some being more realistic than communication networks are the

text: CK others: Compromising a local wireless connection (e.g. Wi-Fi), primary asset targeted, but Local TA Key fob cloning, Relay attack, Rolling code jam, exploiting the ultimately all assets are concerned, AT Keyless systems … in cases where the vehicle is eventually stolen

text: See http://fortune.com/2016/08/06/houston-car-hackers/ It was notably the main point of http://blog.crysys.hu/2015/10/hacking-cars-in-the-style-of-stuxnet/

text: December 2016

text: CRITICALITY LIKELIHOOD

text: Possible Medium

text: CASCADING EFFECTS STAKEHOLDERS INVOLVED

text: Actors providing keyless entry systems (car manufacturers and Tiers), but also Insurance Beyond the theft itself, privacy issues can happen (the same companies, insofar as policies should take into way as the theft of smartphones or tablet may result in account these scenarios and define appropriate private data being accessible by the thief). forensic procedures.

text: RECOVERY TIME GOOD PRACTICES AND EFFORTS

text:  General good practices apply (Policy and standards, organizational measures);  In terms of security functions, Cryptography is obviously the first coming to mind, since most of these attacks rely on the weak cryptography implemented in remote keyless Assuming that most entry systems; vulnerabilities are  Communication protection is obviously needed to mitigate these attacks, and well as software-based, they

text: Identification, authentication and authorization for all actions accessible, for example,

text: may be fixed by an

text: via local wireless entry points (Wi-Fi, keyfob…). Physical self-protection also

text: OTA or physical contributes to reduce the attack surface for local attacks (see 8.1.3.6 for details); update. Hardware  Security Audit may help the forensic analysis of such cases, from an insurance point of vulnerabilities may

text: view, as they are physically undetectable;

text: cause much higher  These functions are supported by self-protection. In particular, the design should allow recovery costs. users to fall back to a mechanical lock whenever a vulnerability is found in their keyless entry systems.

text: CHALLENGES AND GAPS

text: Insecure design or development

text: December 2016

text: See Hacking the Mitsubishi Outlander PHEV hybrid, Pen Test Partners, https://www.pentestpartners.com/blog/hacking-the-mitsubishi-outlander-phev-hybrid-suv/. This is also part of an ongoing series including https://www.pentestpartners.com/blog/hacking-the-mitsubishi-outlander-working-out-theprotocol/ See http://jalopnik.com/5923802/watch-hackers-steal-a-bmw-in-three-minutes See Francillon, A., Danev, B., & Capkun, S. (2011, February). Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars. In NDSS. See https://www.wired.com/2016/03/study-finds-24-car-models-open-unlocking-ignition-hack/ 88 See http://andrewmohawk.com/2016/02/05/bypassing-rolling-code-systems/ See http://www.dailydot.com/technology/cars-vulnerable-to-remote-hacking/ Such as the RollJam, for instance: http://thehackernews.com/2015/08/rolljam-unlock-car-garage.html See Lock It and Still Lose It—On the (In)Security of Automotive Remote Keyless Entry Systems - Flavio D. Garcia, David Oswald, Timo Kasper, Pierre Pavlidès. Proceedings of the 25th USENIX Security Symposium August 10–12, 2016. Austin, TX

text: December 2016

text: Table 6 : Attack scenario 4 - Surveillance

text: private data stored on ECUs and sensors, or

text: There are several different possibilities for

text: in transit through the subnetworks or

text: Local or surveillance in smart cars. We distinguish between

text: external communication networks,

text: remote Targeted Surveillance, Mass surveillance and notably location-aware content, but also

text: Surveillance on cloud-stored data and services.

text: communications or payment data if any

text: CRITICALITY LIKELIHOOD

text: High Unlikely

text: CASCADING EFFECTS STAKEHOLDERS INVOLVED

text: All actors storing or IO processing private data: car Cascading effect may include theft of the user identity, for example to perform manufacturers, Tiers, a financial fraud in a second step. In the case of mass surveillance, ENAR aftermarket providers, app consequences are out of scope of this study. SC providers, cloud service CK providers, garages…

text: TA AT RECOVERY TIME AND EFFORTS GOOD PRACTICES

text:  General good practices apply (Policy and standards, organizational

text: measures). In this case, privacy regulation, may notably contribute to

text: Assuming that most reduce the amount of memorized private data in the first place, thus vulnerabilities are software- reducing the impact of an attack; based, they may be fixed by an  In terms of security functions, Communication protection is obviously OTA or physical update. needed to mitigate these attacks (especially for communication with Hardware vulnerabilities may cloud-based services) as well as Identification, authentication and cause much higher recovery authorization. costs.  These functions are supported by Cryptography, Security Audit, and

text: software self-protection.

text: CHALLENGES AND GAPS

text: Insecure design or development (lack of privacy by design in components or protocols), safety and security process integration

text: https://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/eIDAS_THREAD/S03_eID/DPSECURITYCONSULTIN G_PINKAS.pdf https://docbox.etsi.org/Workshop/2015/201506_SECURITYWEEK/SECURITYWS/S03_OTHERSTANDARDSandINDUSTR YFORA/ISO_IEC_JTC2_SC27_RANNENBERG.pdf See for example https://www.blackhat.com/docs/eu-15/materials/eu-15-Petit-Self-Driving-And-Connected-Cars- Fooling-Sensors-And-Tracking-Drivers-wp2.pdf

text: December 2016

text: See https://www.enisa.europa.eu/publications#c5=2006&c5=2016&c5=false&c2=publicationDate&reversed=on&b_start =0&c8=Cloud+Computing+Security See for example Enev, M., Takakuwa, A., Koscher, K., & Kohno, T. (2016). Automobile Driver Fingerprinting. Proceedings on Privacy Enhancing Technologies, 2016(1), 34-50.

text: December 2016

text: See for example http://www.computerworld.com/article/2684298/once-your-cars-connected-to-the-internet-whoguards-your-privacy.html Such as the OnStar privacy issues described in http://www.autoblog.com/2011/09/26/gm-onstar-privacy/

text: December 2016

text: See https://blog.lookout.com/blog/2015/08/07/hacking-a-tesla/ Markey, E. J. (2015). Tracking & Hacking: Security & privacy gaps put American drivers at risk. US Senate. Progressive insurance dongle totally insecure, http://www.forbes.com/sites/thomasbrewster/2015/01/15/researcher-says-progressive-insurance-dongle-totallyinsecure/

text: December 2016

text: Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S., & Savage, S. (2010, May). Experimental security analysis of a modern automobile. In 2010 IEEE Symposium on Security and Privacy (pp. 447-462). IEEE. For example in Hacking a Tesla https://blog.lookout.com/blog/2015/08/07/hacking-a-tesla/ Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematics failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15). However, the ongoing work on C-ITS and ETSI G5 provides solid bases in this respect For example Hacking a Tesla, https://blog.lookout.com/blog/2015/08/07/hacking-a-tesla/ See https://www.theguardian.com/technology/2015/aug/18/security-flaw-100-car-models-exposed-scientistsvolkswagen-suppressed-paper See Hacking the Mitsubishi Outlander PHEV hybrid - https://www.pentestpartners.com/blog/hacking-themitsubishi-outlander-phev-hybrid-suv/ See https://media.ccc.de/v/32c3-7331-the_exhaust_emissions_scandal_dieselgate#video&t=663 Or Security Audit, in the Common Criteria parlance See for example Responsibility for Vehicle Security and Driver Privacy in the Age of the Connected Car, IDC/Veracode, February 2016, IDC #EMEA41026016

text: December 2016

text: Generally, the term “glue code” is used for the code binding diverse software components together, typically written in a dynamic scripting language, as opposed to the static compiled software components. In the context of security, glue code is considered a threat for it often implies bad understanding of the security assumptions of the third-party component code. See SAE-J 3061 - SURFACE VEHICLE RECOMMENDED PRACTICE - Cybersecurity Guidebook for Cyber-Physical Vehicle Systems Amongst possible lifecycle adaptation, one may think of the following : - Adding a dedicated interface design review; - Adding a dedicated hardening phase during the late integration phases. This combination implies that smart car security should require a high security assurance. And yet, the SAE-J3061 does not explicitly suggest high assurance certification (for example, Common Criteria EAL4+ security hardware) This situation should theoretically require smart car manufacturers to reach a consensus on future-proof cryptographic key sizes, which may exceed the usual recommendations of national cyber-security agencies. As such, a consensus could be reached amongst manufacturers to define an “offline mode” where cars would be functional while deactivating most of the external interfaces, such as the infotainment. Such a mode could be an option when sever flaws have been found and are not yet patched. See https://www.iamthecavalry.org/domains/automotive/5star/ See https://www-ssl.intel.com/content/www/us/en/automotive/automotive-security-review-board.html See http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=70918

text: December 2016

text: Figure 9 : Safety and security initiatives inside and outside of the automotive domains

text: See Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., & Kohno, T. (2011, August). Comprehensive Experimental Analyses of Automotive Attack Surfaces. In USENIX Security Symposium. See Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S. & Savage, S. (2010, May). Experimental security analysis of a modern automobile. In 2010 IEEE Symposium on Security and Privacy (pp. 447-462). IEEE.

text: December 2016

text: See Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematics failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15). See Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., & Kohno, T. (2011, August). Comprehensive Experimental Analyses of Automotive Attack Surfaces. In USENIX Security Symposium. See SAE-J 3061 - SURFACE VEHICLE RECOMMENDED PRACTICE - Cybersecurity Guidebook for Cyber-Physical Vehicle Systems See for example Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematic failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15).

text: December 2016

text: See Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S., & Savage, S. (2010, May). Experimental security analysis of a modern automobile. In 2010 IEEE Symposium on Security and Privacy (pp. 447-462). IEEE. The newly introduced CAN FD which may solve the small packet issues could be potentially used for security enabled messages. See Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., & Kohno, T. (2011, August). Comprehensive Experimental Analyses of Automotive Attack Surfaces. In USENIX Security Symposium. See http://www.autosec.org/pubs/cars-usenixsec2011.pdf See http://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf For example "An unknown 4-pin connector" in Hacking a Tesla https://blog.lookout.com/blog/2015/08/07/hacking-a-tesla/ Responsibility for Vehicle Security and Driver Privacy in the Age of the Connected Car, IDC/Veracode, February 2016, IDC #EMEA41026016

text: December 2016

text: Table 7 : Motivators and incentives, as selected by interviewees (most critical in bold)

text: CATEGORY MOTIVATORS/INCENTIVES

text: Enabling business opportunities

text: Protecting an organization’s reputation Business incentives

text: Improving efficiencies/reducing-costs

text: Protecting intellectual property

text: Protecting users’ personal freedom and privacy

text: Protecting physical integrity of customers / users

text: Customer incentives Protecting users’ confidential information (such as payment data)

text: Maintaining data integrity

text: Protecting the physical integrity of users’ cars, or deter theft

text: Complying with regulation/legal requirements

text: Regulation and infrastructure

text: Protecting the overall transport infrastructure, ensuring continuity of service in a disaster situation

text: See A Summary of Cybersecurity Best Practices, NHTSA See for example "Automotive Cyber Security: An IET/KTN Thought Leadership Review of risk perspectives for connected vehicles", the IET See https://www.transportation.gov/AV See https://www.nist.gov/cyberframework

text: December 2016

text: Figure 10: Summary of good practices

text: CATEGORY GOOD PRACTICES ASSOCIATED ATTACKS

text: GP-PS-01 – Adherence to regulation. Industry actors shall, as a first step, adhere

text: to regulation related to security and privacy.

text: Policy and standards GP-PS-02 – Liability. The question of liability needs to be addressed. The question of where liability may fall lies between Tier actors, car manufacturers, the All vendors, aftermarket support operators and the end users. The liability issues

text: December 2016

text: have to be addressed in the context of national legislation and case law. Where

text: gaps are identified in national legislation, these should be addressed.

text: GP-PS-03 – Traceability. Car manufacturers and Tier actors shall ensure that

text: appropriate technical measures (e.g. logging, distinct authentication, transparency provided through OEM/Tier sites concerning each particular All car/component, integration with Type Approval authorities and monitoring

text: agencies) exist allowing for tracing liability between actors.

text: ASSOCIATED CATEGORY GOOD PRACTICES ATTACKS

text: GP-OM-01 - Designate a dedicated security team. Actors of the smart car industry should rely on specialists, notably for secure design, penetration testing and risk

text: management. Expert advice for training and corporate security is also All recommended. Some efforts in this direction are done in the ISO AWI 21434 –still in Organizational draft- (see also Section 8.1.2). measures – general GP-OM-02 - Define a dedicated Information Security Management System (ISMS). Actors of the smart car industry should define an ISMS, possibly inspired from SAE J3061, ISO 27001 or NIST 800-53, and refine it to address the specific needs of their All

text: industry, notably the management of Tier-1 and Tier-2 actors, and processes to ensure continuous isolation of the components from aftermarket products.

text: GP-OM-03 - Assess the threat model and use cases. Actors of the smart car

text: industry should perform a threat analysis prior to development possibly inspired from SAE-J3061 TARA approach (including EVITA, TVRA, OCTAVE and HEAVENS All methods) or possible from the risk management approach of ISO 31000. Efforts in

text: this direction are also done in the context of ISO AWI 21434.

text: GP-OM-04 - Provide security and privacy by design. Actors of the smart car

text: Organizational industry should plan their development lifecycles to ensure that security and measures – All

text: privacy are taken into account no later than the design phase, in order to address

text: the threats identified in the risk assessment.

text: GP-OM-05 - Implement and test the security functions. Actors of the smart car

text: industry should clearly define appropriate security functions that will be explicitly

text: implemented and tested during the development lifecycle. Security functions

text: All described in the next section, include Security Audit, Communication protection, Cryptography, User data protection, Identification, authentication, authorization, and Self-protection.

text: GP-OM-06 - Assess the security controls and patch vulnerabilities. Actors of the

text: smart car industry should define appropriate assessment procedures to regularly All check the effectiveness of their security functions, and patch them whenever

text: needed.

text: Organizational GP-OM-07 - Define a security update policy. Actors of the smart car industry

text: should define an update policy for security patches, taking into account appropriate

text: measures –

text: timing, conditions, and user awareness for the updates (to ensure safety during

text: security until All the update), and OTA update mechanisms whenever possible. Manufacturers may the end-of-life have to define whether a vulnerable component can, or should, be put offline when proven vulnerable.

text: GP-OM-08 - Perform a vulnerability survey. Actors of the smart car industry should

text: perform a vulnerability survey to be proactively able to fix security issues before All they can be used in the wild. The vulnerability survey should include developer

text: December 2016

text: findings, on-line researches, CERTs advisories, information shared by groups such as CarSec, ISACs or AutoSAR, as well as input from customers and security researches. Eventually, vulnerabilities impacting user data should be communicated as transparently as possible, as expressed by the EU Opinion 03/2014 on Personal Data Breach Notification from the

text: Article 29

text: Working Party.

text: GP-OM-09 - Check the security assumptions regularly during life-time. The devices

text: and services made assumptions to ensure that the security requirements are sufficient (limitations in the usage of the vehicle , assumed properties of the All 138 139 environment , assumed properties of cryptographic properties …). Vendors and

text: users should be encouraged to check regularly that these assumptions are still valid.

text: GP-OM-10 - Protect the software update mechanism. Vendors should protect the

text: updates (typically via encryption and digital signature) and protect the application All of an update on the device. Eventually, the update server and infrastructure

text: (including diagnostic tools) should also be protected.

text: GP-OM-11 - Raise user awareness. Vendors and public authorities should explain users what actions can contribute to mitigate potential threats, especially how to securely use interfaced systems such as a smartphone. All In the other side, a car owner often does not know what was changed in his car. OEM shall support users by setting up issue-tracking sites where users can track changes of their cars and report problems.

text: GP-SF-01 - Security events must be securely logged. Access to the logs must be

text: documented and protected from disclosure to unauthorized users. The audit trail All must be protected from unauthorized access. Security functions – Security audit GP-SF-02 – Users must be informed of security events. HW and embedded systems should provide clear error data that can be leveraged upon by the SW All vendors. The user must be informed in case of security errors, updates or

text: compromised data in a device or service they use.

text: GP-SF-03 - Provide end-to-end protection in confidentiality and integrity using

text: Security functions – protocols that resist to replay attacks. Favour methods providing forward secrecy Remote attacks, Communications whenever possible, for WAN traffic (internet, mobile network) as well as local theft, surveillance protection networks.

text: For example, users may be advised to remove connectivity features from their entertainment system until a fix has been found for a given vulnerability For example, vendors should perform a survey to be able to remove a compromised CA from the certificate store. Vendors should check regularly this assumption. For example, vendors should be aware to new cryptographic attacks in order to adapt users’ key length or cryptographic suites adequately. See for instance FBI’s public announcement Motor vehicles increasingly vulnerable to remote exploits See National Institute of Standards and Technology cyber security risk management framework applied to modern vehicles

text: December 2016

text: GP-SF-04 - Mitigate vulnerabilities or limitations of standard security library.

text: Developers must be aware of the vulnerabilities and limitations of the third-party components they use. They should mitigate them whenever possible by patching All and by securing the configuration of the communication stacks, which might typically include Bluetooth, Wi-Fi, TLS…

text: GP-SF-05 - Consider denial of service as a usual threat to communication infrastructures. This good practice contributes to data availability. Vendors and

text: Remote attacks service providers are encouraged to read the ENISA Internet Infrastructure Threat Landscape (for network components) .

text: GP-SF-06 - Protect remote monitoring and administration interfaces. Vendors

text: Remote attacks, should protect all monitoring and administration interfaces by mutual theft authentication and access control mechanisms.

text: GP-SF-07 - Do not create proprietary cryptographic schemes, but use state-ofthe-art standards instead. If needed, consider getting advice from security

text: experts or your national cybersecurity agency. C-ITS platform could also be used for advices. If no recommendations exist for vendors at a national level, ENISA recommendations should be considered as a reference . This applies also to random number generation, which is a critical part of the All cryptographic support, which should meet quality measures on statistical output (for example based upon national requirements ). Additionally, consider the expected life duration of the vehicle and find advice on the relevant key size (national recommendations might, in some cases, be based on shorter lifespans than a consumer car).

text: GP-SF-08 - Rely on an expert in cryptography, notably for interfacing with HW

text: accelerated cryptography or secure elements, or even using or configuring a standard implementation. At least, code review should be performed to ensure Security functions - All that HW or a standard implementation of cryptography is properly used. The code cryptography review would ideally be performed by a third party, but independent internal code reviews can also be of a high quality.

text: GP-SF-09 - Consider using dedicated, and independently audited, hardware security modules. The standard for independent assessment of security HW

text: Persistent vehicle should be either FIPS 140-2, or a Common Criteria certification following relevant alteration Protection Profiles. If needed, consider getting advice from security experts or your national cybersecurity agency.

text: GP-SF-10 - Cryptographic keys should be securely managed, which means

text: securely generated, distributed (or provisioned), used, stored, and deleted (including revocation). Manufacturers, as well as Tier-1/Tier-2 and aftermarket vendors should consider very carefully the revocation mechanisms associated All with their components, especially for OTA provisioning or key management. If needed, consider getting advice from security experts or your national

text: cybersecurity agency.

text: See https://www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/enisa-thematiclandscapes/threat-landscape-of-the-internet-infrastructure http://ec.europa.eu/transport/themes/its/c-its_en.htm See https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-andparameters-report-2014 See for example A proposal for: Functionality classes for random number generators, Version 2.0 , 18 September 2011, by the BSI, and http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf

text: December 2016

text: GP-SF-11 - Identify personal data. Vendors should identify all data relating to an

text: identified or identifiable person. In the case of smart cars, this may especially Surveillance include location-based data. Consider getting advice from your national data

text: protection agency.

text: GP-SF-12 - Implement transparency measures. The interactions with the user

text: (which should not be limited to the Terms and conditions) enable to cover the Surveillance

text: legal transparency requirements.

text: GP-SF-13 - Design the product/service with legitimate purpose and proportionality in mind. The actors must ensure that themselves and their

text: subcontractors or suppliers do not process user data more than needed, and do Security functions – not pursue an illegitimate purpose with regard to user data. As a general rule, Surveillance User data third party components integrated in the device or third party cloud services protection should not access user data that have not been anonymized or pseudonymized

text: unless user agreement has been obtained.

text: GP-SF-14 - Define access control, anonymity and unlinkability measures to enforce the protection of private data. These measures are typically access

text: control measures, pseudonymity and unlinkability measures (such as ensuring 146 Surveillance that data is not correlated)) , and eventually anonymity measures. Anonymity measures may be “one-way” or “non-reversible” (such as truncation or a hash

text: functions) or “reversible” such as encryption.

text: GP-SF-15 - Define measures to ensure secure deletion of user data in case of a

text: change of ownership. More generally, a secure factory-reset of the firmware and Surveillance

text: configuration should be available on the vehicle.

text: GP-SF-16 - Use mutual authentication for remote communication. Devices or

text: users connecting to a server must be able to authenticate the server. Reciprocally, Remote attacks servers must be able to authenticate clients and users146.

text: GP-SF-17 - Use multi-factor authentication for user authentication. Users should

text: Remote attacks, be authenticated by 2-factor authentication whenever possible, including for persistent vehicle authentication to cloud services or mobile interfaces, as well as local alteration, theft

text: administration sessions of devices.

text: GP-SF-18 - Implement access control measures to separate the privileges of different users and the privileges of different applications as well as to ensure

text: Security functions - Identification, traceability of access and modifications. In practice, privileged operations should Remote attacks, authentication, not be readily accessible to normal users. Implementing privilege levels, rings or persistent vehicle authorization domains can also be extended to application separation. alteration, theft OEMs and Tier Actors shall employ a sufficient and flexible infrastructure for “distinct” cryptographic keys per Tier Actors, garage personnel or vehicle owner .

text: GP-SF-19 - Allow and encourage the use of strong passwords. This concerns all

text: possible uses of passwords: direct device interfaces such as JTAG, but also web, Remote attacks, mobile or cloud interfaces. However, the use of passwords in general may cause persistent vehicle safety issues for user interactions in a moving vehicle; this good practice is alteration, theft recommended mainly for setup and pairing activities, and especially for

text: administration or diagnostic features.

text: See C-ITS Platform, Final report, January 2016 – C-ITS Working Group 4 on Data protection and privacy – http://ec.europa.eu/transport/sites/transport/files/themes/its/doc/c-its-platform-final-report-january-2016.pdf See also http://ec.europa.eu/transport/themes/its/c-its_en for the key distribution.

text: December 2016

text: Remote attacks,

text: GP-SF-20 - Enforce session management policies to avoid session hijacking. persistent vehicle

text: alteration, theft

text: GP-SF-21 - Provide the user with mechanisms to securely erase their private data. For client information in remote infrastructures such as cloud services, data

text: sanitization must be in place. For user data present on vehicles, secure deletion of Surveillance

text: encryption keys may provide enough protection, assuming that data is encrypted

text: in conditions that guarantee long-term confidentiality.

text: GP-SF-22 - Define a consistent policy for self-protection. Vendors should

text: Persistent vehicle challenge every security function of their design, consider how they could be alteration, theft

text: bypassed or weakened, and eventually implement self-protection measures.

text: GP-SF-23 – Implement Hardware self-protection. Vendors should define

text: Persistent vehicle measures to protect hardware against physical attacks or observation. This alteration, theft includes tamper evidence or tamper resistance, and secure design measures.

text: GP-SF-24 – Implement Software self-protection. Vendors should define measures

text: Remote attacks, to protect existing security functions, typically by validating inputs and outputs, or persistent vehicle by separating the capacities of the different software components (levels of trust, alteration, theft

text: virtualization…).

text: Security functions – Remote attacks, self-protection GP-SF-25 – Protect Non-user data. Vendors should protect data enforcing the persistent vehicle

text: security functions, such as keys or configuration data.

text: alteration, theft

text: GP-SF-26 – Perform Hardening. Vendors should actively reduce the attack surface

text: of the product or device. This includes removing or disabling unused services or Remote attacks, interfaces (especially debug interfaces), providing secure configuration by default, persistent vehicle as well as integrating malware protection. Some actors may consider intrusion alteration, theft detection systems for internal subnetworks (for example CAN bus monitoring),

text: although this study will not conclude on the merits of these solutions.

text: GP-SF-27 – Isolate components. Vendors should reduce the capacity for attackers Remote attacks,

text: to jump from a component to another, either by a physical disconnection or by persistent vehicle

text: using gateways. alteration, theft

text: December 2016

text: 149 Communities for information sharing already exist, such as the US Auto-ISAC and the CarSEC group built by ENISA. This report recommends pursuing this effort and consider developing an automotive incident response capabilities.

text: See https://www.automotiveisac.com/ See https://resilience.enisa.europa.eu/carsec-expert-group

text: December 2016

text: See http://www.globalplatform.org/specificationform.asp?fid=7828

text: December 2016

text: December 2016

text: 153 Some initiatives ask for collaboration on the security topics from the automotive industry, and suggest dedicated security testing from actors skilled in penetration testing. Also, AUTOSAR and GENIVI have established their own security projects, led by security experts.

text: https://www.iamthecavalry.org/domains/automotive/5star/ https://www-ssl.intel.com/content/www/us/en/automotive/automotive-security-review-board.html

text: December 2016

text: December 2016

text: ACRONYM DEFINITION

text: ABS Anti-lock Braking System ADAS Advanced Driver Assistance Systems AGL Automotive Grade Linux BTS Base Transceiver Station CAN Controller Area Network DoS Denial-of-Service attack ECU Electronic control unit EV Electric Vehicle GNSS Global Navigation Satellite System HSM Hardware Security Module HUD Heads-up display HW Hardware IoT Internet of Things IoV Internet of Vehicles ITS Intelligent transportation system MitM Man-in-the-Middle MSIN Mobile Subscription Identification Number OBD On-board diagnostic OEM Original Equipment Manufacturer OS Operating System OTA Over-The-Air PKI Public Key Infrastructure RF Radio Frequency SDO Standards Developing Organizations SMS Single Messaging System SoC System-on-Chip SoC State of Charge SW Software

text: December 2016

text: ACRONYM DEFINITION

text: TCU Telematics control unit TPM Trusted Platform Module TPMS Tire Pressure Monitoring Systems TVRA Threat Vulnerability Risk Assessment Includes the notions of V2X - Vehicle-to-Vehicle communications - Vehicle-to-Infrastructure communications - Vehicle-to-Pedestrian communications

text: December 2016

text: December 2016

text: Table 8 : Risk rating for the scenarios

text: E L H D T T Y IA O C F T T Y E IT A N N HO IT P IS O E E S E T E T M E M N G TUN O ELI

text: SCENARIO RELATED ASSETS I IM O P

text: E ER D T R P K T T P ET O UI RISK X LE LI S P Q CK IN S E W P E K A O O TA IS N T R K A

text: Attacks threatening vehicle systems, including vehicle High > 6 High Expert Public Moderate Standard High Unlikely Major passengers safety systems intensity months safety

text: The assets primarily targeted are mostly related to access control, especially access to functions not intended for users (fleet management, digital tachograph, geo-fencing...). Studies give example of privileged services than can be compromised because static keys were discovered 2. Persistent by a memory dump (for example SSH vehicle keys ) Single <= 1 alteration by Other targeted assets are the driving High Proficient Restricted Easy Standard Moderate Possible Critical instance month the legitimate systems, especially in cases where user the user tries to modify the performance of their

text: vehicle safety systems may also be

text: at risk due to accidental side effects of the attack. Modified traffic on the CAN bus may for example trigger denials of service on the bus, or otherwise cause dangerous situations to arise on vehicle systems

text: Persistent IP and Trade secrets may be Moderate <= 1 High Expert Restricted Moderate Specialized High Unlikely Major vehicle targeted. intensity month

text: December 2016 alteration by In a context related to organized diagnostic crime, the assets are more likely to be equipment vehicle safety systems, driving

text: systems or private data (especially

text: payment data)

text: The vehicle itself, the content of the vehicle (owner’s possessions) [and any Single <= 1 4. Theft Medium Proficient Public Moderate Standard Moderate Possible Major data accessible through the head-up instance month unit]

text: private data, notably location-aware

text: 5.1 Targeted Single <= 6 content, but also communications or Medium Expert Public Easy Standard High Unlikely Minor Surveillance instance months payment data if any

text: private data, notably location-aware

text: 5.2 Mass Moderate > 6 content, but also communications or Medium Expert Public Moderate Specialized High Unlikely Major surveillance intensity months payment data if any

text: 5.3 private data, notably location-aware High <= 3 Surveillance content, but also communications or Medium Expert Public Unnecessary Standard High Unlikely Major intensity months (via cloud) payment data if any

text: Table 9 : rationale for the rating

text: SCENARIO EXPLANATION OF THE RATING

text: Intensity is considered high, since the attack typically allows to be performed by several agents at a time (exploit kit), or to be performed on several vehicles at a time (sequentially assigned phone numbers). Asset impact is high, since safety is at risk. Time, expertise, 1. Attacks threatening knowledge of the ToE and equipment are all rated in a way that reflects existing attacks made by researchers (for example Miller and passengers safety Valasek). Opportunity is estimated at "moderate" as an attacker can work on their own vehicle, which means it still is expensive, and restricts the number of models on which the attacker can work.

text: Intensity is rated as "single instance", since a physical access is required. Impact is rated as high. The attacker may damage their vehicle beyond repair, and may also put their own safety at risk. Expertise is rated as proficient, since the scenario is typically aimed at proficient 2. Persistent vehicle users trying to tune or modify their own vehicle. Knowledge of the TOE is supposed to be "restricted": online communities are a factor of alteration by the information-sharing for this public, and information known only by garages may be found in such communities. Time is rated under a legitimate user month for the same reason. Opportunity is estimated at "easy", since an attacker typically work on their own vehicle (even if one may argue that the vehicle is still, and restricts the number of models on which the attacker can work. Equipment is supposed to be standard.

text: Intensity is moderate because while it needs a vehicle to be accessed via diagnostic equipment, an example of this has been described as 3. Persistent vehicle repeatable on a wide range of models. Asset impact is high due to the potential safety risk. Time is estimated at under 3 months. Expertise alteration by is "expert" because the attacker needs car-specific knowledge (to alter an ECU firmware), as well as they need to know how to reverse a diagnostic equipment DLL and exploit bad digital signature implementations. Knowledge of the TOE is expected to include "restricted" information, due to the attacker having potentially access to restricted diagnostic tools and data. Opportunity is rated at "moderate" since most of the work is

text: December 2016 performed on the DLL, which is more readily accessible than the vehicle. Equipment is rated at "specialized" since an access to diagnostic tools will be needed at some point. Intensity is considered "single instance": while it can be repeated on several vehicles of the same model, there is still needs a physical access for each (since theft is the ultimate goal). Impact is medium (as opposed to safety issues that are considered High). Time is 4. Theft estimated at under 1 month, to reflect the fact that information sharing within criminal networks may contribute to a relatively easy reproducibility of attacks. Expertise is estimated at proficient, since the simplest methods are similar to remote control hacks that are already used today [reference needed]. Opportunity is moderate. Only standard equipment is required 5.1 Targeted Intensity is by definition "single instance". The impact is considered Medium, since safety may only be threatened in a second step Surveillance Time is supposed to be inferior to 6 months, since a physical access is possible Intensity is "Moderate", since it is only repeatable for cars having a given set of vulnerabilities. The impact is considered Medium, since 5.2 Mass surveillance safety may only be threatened in a second step Time is supposed to be superior to 6 months, since a remote exploitation is needed Intensity is "High", since it is repeatable for all vehicles using the same cloud services (possibly whole fleets for a leasing company, etc.). 5.3 Surveillance (via The impact is considered Medium, since safety may only be threatened in a second step cloud) Time, expertise, opportunity and equipment are rated to reflect that the technical domain is widely known to potential attackers (Cloud APIs and interfaces)

text: December 2016

text: Table 10: Policy enforcement good practices as selected by interviewees

text: POLICY AND STANDARDS DETAILS

text: Enforce liability manufacturer for tier-1 and tier-2 Enforce liability manufacturer for damages due to compromised garage Adhere to regulation -

text: Table 11 : Organizational measures as selected by interviewees

text: ORGANISATIONAL MEASURES GOOD PRACTICE

text: Design Pen-testing Designation of a security team Risk management Corporate security Training and awareness

text: Information Security Management

text: Define an ISMS (ISO 27001, NIST 800-53, SAE J3061 section 7…)

text: Automotive Security Engineering Follow ISO/AWI 21434

text: December 2016

text: See section 7 of SAE-J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems, January 2016 See for example section 5 of SAE-J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems, January 2016 http://www.commoncriteriaportal.org

text: December 2016

text: December 2016

text: http://ec.europa.eu/justice/data-protection/article-29/documentation/opinionrecommendation/files/2014/wp213_en.pdf See for example https://www.sogeti.com/explore/press-releases/Sogeti-sets-up-a-security-operations-center-forthe-Renault-Group/ See for example Vulnerability Note VU#615456 - Lemur Vehicle Monitors BlueDriver LSB2 does not authenticate users for Bluetooth access - http://www.kb.cert.org/vuls/id/615456 See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right https://www.youtube.com/watch?v=WHdU4LutBGU See FTC, Careful Connections - https://www.ftc.gov/tips-advice/business-center/guidance/careful-connectionsbuilding-security-internet-things See also the global bounty aggregator https://firebounty.com See Symantec Insecurity in the Internet of things, March 12, 2015 or FTC - Careful Connections For example, users may be advised to remove connectivity features from their entertainment system until a fix has been found for a given vulnerability For example, vendors should perform a survey to be able to remove a compromised CA from the certificate store. For example, vendors should check regularly this assumption, for example if a new cryptographic attack puts users at risk unless they use longer keys or change their cryptographic suites.

text: December 2016

text: see Symantec Insecurity in the Internet of things, March 12, 2015 and Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group SSee Symantec Insecurity in the Internet of things, March 12, 2015 and OWASP I9 | Insecure Software/Firmware See OWASP I9 | Insecure Software/Firmware See Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematic failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15). See National Institute of Standards and Technology cyber security risk management framework applied to modern vehicles See Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group and see OWASP I8 | Insufficient Security Configurability Such protection can typically consist in the following practices  Logs should be anonymous;  Avoid logging information that would give useful information to an attacker ;  Access control mechanisms should limit the access to the logs;  When sent to a remote system, logs should be protected by cryptographic mechanisms

text: December 2016

text: See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right See OWASP I8 | Insufficient Security Configurability Developers should be aware that for some functions, an excess of clarity is a valuable information for an attacker. As a common example, when a login fails, the product should not communicate to the user whether the error is due to a non-existent login or a bad login/password combination. The optimal balance between not enough or too much clarity is to be assessed during dedicated security testing. See OWASP I9 | Insecure Software/Firmware, or Symantec Insecurity in the Internet of things, March 12, 2015. Many protocols use both transport layer and applicative layer protection. The need for applicative layer protection comes from end-to-end protection needs: the transport layer could be exposed if different transport technologies are used during the transmission, therefore needing a dedicated protection:  In TCP communications, TLS 1.2 is the default choice for securing the transport layer;;  Applicative layer can be protected by recognized cryptographic means, so as to protect confidentiality and integrity of the payload. See OWASP I4 | Lack of Transport Encryption Third-party and open-source libraries need frequent patching: vulnerabilities are regularly found in all most opensource implementations, even those considered as “industry standard”. Communications protection work only as long as firmware updates are available and applied to fix vulnerabilities. Due to the existence of vulnerabilities in frequently used protocol implementations, configuration of the library is a significant part of the security functionality. Developers should in particular be vigilant to the configuration of cipher suite negotiation and key sizes: allowing weak cipher suites provides an entry point for attacks aiming at downgrading the level of security of the exchanges (See for example CVE-2015-0204 at https://cve.mitre.org/cgibin/cvename.cgi?name=CVE-2015-0204) See the example of Bluetooth, including Bluetooth 4.0, in Guide to Bluetooth Security - Recommendations of the National Institute of Standards and Technology - John Padgette, Karen Scarfone, Lily Chen See for instance attacks on WEP http://eprint.iacr.org/2007/120.pdf , WPS PIN vulnerability https://www.kb.cert.org/vuls/id/723755 or the Pixie Dust attack on WPS https://passwordscon.org/wpcontent/uploads/2014/08/Dominique_Bongard.pdf SSL and TLS have a long history of security vulnerabilities (see https://tools.ietf.org/html/rfc7457 ). See OWASP I3 | Insecure Network Services

text: December 2016

text: See https://www.enisa.europa.eu/activities/risk-management/evolving-threat-environment/enisa-thematiclandscapes/threat-landscape-of-the-internet-infrastructure http://www.gsma.com/connectedliving/gsma-iot-device-connection-efficiency-guidelines/ The main reasons for this are that:  phone numbers can be spoofed.  whitelists are not secret  whitelists may be changed by other SMS commands (administration commands). See for example see Symantec Insecurity in the Internet of things, March 12, 2015 or Careful connections by FTC This study will not delve into the detailed requirements for cryptographic algorithms or acceptable keys sizes. One can refer to “Algorithms, key size and parameters” report of Enisa (2014). See https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-andparameters-report-2014 See examples in http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf

text: December 2016

text: Random number generators are a good example of vulnerable functions with an impact on many features.  As a general rule, a true random number should be used for key generation, but may not be required for salts, initialization vectors… where a cryptographically secure pseudo-random number may be sufficient. One may argue that using a cryptographically secure software pseudorandom number generator is more secure than a badly implemented hardware “true random number generator”;  When using hardware claiming a “true random”, developers should consider using strong post-processing functions. The functions used for that purpose are typically block encryption or hash functions; More details on the different categories of random generators can be found in documents from national cybersecurity agencies. See in particular A proposal for: Functionality classes for random number generators, Version 2.0, 18 September 2011, by the BSI. Industry players introduced the notion of remote provisioning for mobile communication (See for example GSMA remote provisioning architecture and Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group). While keys are loaded in SIM cards in protected environment, the “embedded UICCs” rely on remote subscription management systems to obtain key material. The protection of these exchanges is consequently critical and must be assessed accordingly by manufacturers and vendors. Should the keys be leaked, the user and the vendors could be at risk in many ways (loss of control over the device, eavesdropping, credential theft, cloning…). More generally, the notion of confidential key agreement must be considered in IoT in general, and smart cars in particular. This study will not delve into the detailed requirements for cryptographic algorithms or acceptable keys sizes, since national cybersecurity agencies already provide consistent guidance on this topic

text: December 2016

text: See http://www.lifehacker.com.au/2015/02/why-the-internet-of-things-is-a-problem-for-metadata-retention/ While the Terms and Conditions are a practical support for the vendors, many actors consider that this cannot be considered a good practice. In particular, the user may be lost in a barely-legible legalese instead of being able to make informed choices regarding their privacy. The US FTC gives recommendations on this topic, for example using other supports such as registration emails. The service or device provider must communicate • The provider’s name and address; • What data is collected, in layman terms; • The purpose of processing, explaining notably why the processing is necessary for the performance, to protect the vital interests of the data subject, or for compliance with a legal obligation; • The recipients of the data; • How the user can: o Access all data processed about him, o Require the rectification, deletion or blocking of data that is incomplete, inaccurate or isn't being processed in compliance with the data protection rules. • And all other information required to ensure the processing is fair; • The service or device provider must require the consent of the user (or “data subject”). On top of legal requirements, actors might also consider: • Defining a strict opt-in policy; • Enabling rectification, deletion or blocking of data without a reason; • Ensuring data portability. As a general rule, access to sensitive data should be controlled. For web services and components including virtualization, access control could be completed by data isolation The typical example is ensuring that the key used to browse the “customer database” is not the same as the key used to browse the “usage analytics database”. However the situation is more complicated in practice: in the case of smart cars, for example, network locator is a critical factor of linkability and should be taken into account accordingly. Vendors should also be aware, that unlinkability can also: • Cause trust issues and reduce attack mitigation capabilities (for example if a user cannot be notified that their device is compromised); • Cause a conflict with other legal requirements. There is no one-size-fits-all good practice to balance unlinkability against other desired properties. The right balance must be defined during the design stage by examining the associated risks.

text: December 2016

text: 201 “one-way” or “non-reversible” (such as truncation or a hash functions ) or “reversible” such as encryption .

text: Truncation is often used in the payment industry to anonymize cardholder data (see https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf ) Hash functions also have vulnerabilities (see for example https://en.wikipedia.org/wiki/Cryptographic_hash_function). As for other cryptographic operations, robust standard mechanisms should be preferred – vendors are encouraged to contact their national cybersecurity agency if needed. See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right, OWASP I5 | Privacy Concerns and OWASP I10 | Poor Physical Security. As a sidenote, encrypted storage can also address authenticity or integrity of user data if combined with the right mechanisms (for example AES-GCM). SSee Symantec’s “Insecurity in the Internet of things”, March 12, 2015 See Home Automation Benchmarking by SYNACK, but also Making Smart Locks Smarter (aka. Hacking the August Smart Lock), The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right. See Home Automation Benchmarking by SYNACK or Making Smart Locks Smarter (aka. Hacking the August Smart Lock). For details on Certificate pinning, see https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#What_Is_Pinning.3F see OWASP I2 | Insufficient Authentication/Authorization, I6 | Insecure Cloud Interface, I7 | Insecure Mobile Interface See NIST Special Publication 800-63-2 – Electronic Authentication Guideline

text: December 2016

text: See for example Foster, I., Prudhomme, A., Koscher, K., & Savage, S. (2015). Fast and vulnerable: a story of telematic failures. In 9th USENIX Workshop on Offensive Technologies (WOOT 15). I5 | Privacy Concerns See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right See OWASP I8 | Insufficient Security Configurability See "Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group" See for example Fast and Vulnerable: A Story of Telematic Failures, Ian Foster, Andrew Prudhomme, Karl Koscher, and Stefan Savage See I2 | Insufficient Authentication/Authorization and OWASP I1 | Insecure Web Interface; See also see Symantec Insecurity in the Internet of things, March 12, 2015 See OWASP I1 | Insecure Web Interface, OWASP I6 | Insecure Cloud Interface, OWASP I7 | Insecure Mobile Interface See https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet. Hash functions such as MD5, SHA should not be used for password protection, and even SHA256 or SHA3 would lack the additional work factor to be efficient in a password storage context

text: December 2016

text: see Symantec Insecurity in the Internet of things, March 12, 2015 see OWASP I2 | Insufficient Authentication/Authorization See OWASP I2 | Insufficient Authentication/Authorization and OWASP I8 | Insufficient Security Configurability An example of policy can be found at https://www.sans.org/security-resources/policies/general/pdf/passwordprotection-policy. Policies may vary depending on the threat analysis and dimensions (such as password length) also depend on attacker’s capabilities, especially the computing power, which grows constantly over time. Vendors are invited to contact their national cybersecurity agency or CERT to stay informed of the state-of-the-art. See http://www.enisa.europa.eu/media/news-items/basic-security-practices-regarding-passwords-and-onlineidentities See OWASP I2 | Insufficient Authentication/Authorization See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right See for example Veracode White Paper – The Internet of Things: Security Research Study, 2015, and also The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right

text: December 2016

text: Hardware protection measures are related to: - threats that are not related to privacy, and where the user itself is the attacker (for example fraud use cases); - threats to equipment that is not protected by physical measures. These are also related to attackers with very high skills and motivation profiles (which is for example the model used in smartcards this includes for example: - Use of tamper-resistant hardware such as Active shields; - Protection against glitch; - Protection against fault injection; - Protection against side channels (for example electromagnetic or power analysis). Examples can be found for example in Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group. Even if this level of security cannot be required for all smart home devices, several physical protection measures can be recommended to ensure a better overall security on the device. There are existing self-protection technologies (such as CFI - control flow integrity-) that allows to resist in memory attacks such as ROP. These types of attacks are very common in IT, and are finding their way into IoT these days. Efforts to develop a proven secure OS have already been started:http://www.provenrun.com/wpcontent/uploads/2016/02/Proven-Security-for-the-Internet-of-Things-v2.pdf See http://www.automotiveitnews.org/articles/572873/car-hacking-can-be-stopped-by-ips-from-argus-cyber/ See for example http://iotbusinessnews.com/2016/06/08/34788-symantec-launches-new-iot-solution-helpcarmakers-protect-zero-day-attacks/ or http://www.automotiveitnews.org/articles/572873/car-hacking-can-bestopped-by-ips-from-argus-cyber/

text: December 2016

text: See for example Responsibility for Vehicle Security and Driver Privacy in the Age of the Connected Car, IDC/Veracode, February 2016, IDC #EMEA41026016 This includes typically: • Basic to moderate “Tamper resistance” mechanisms, which will slow an attacker (this typically includes specific sealing methods for the casing, or the use of epoxy to protect components, or the entire board); • Basic to moderate “Tamper evidence” mechanisms, such as tamper-evident seals or labels, or even switches or sensors (light, power…) that will trigger a tamper response; • Basic to moderate “tamper response” mechanisms such as sending an alarm to a remote service, logging a security error or erasing sensitive data. Introduction to Embedded Security, Joe Grand, Black Hat USA 2004 Physical protection: Anti-tamper mechanisms in Common Criteria security evaluations, Epoche & Espri, ICCC Norway 2010

text: December 2016

text: In particular: • Memory (including memory controller) can include measures such as secure erase and wear levelling, Direct memory access, Non executable memory, …; • Printed Circuit Board (PCB) design can contribute to security by including blind and buried vias, buried bus lines, or electronic fuses and similar techniques, for example to deactivate JTAG access (other uses can also be considered). • System on Chip (SoC) design can include some of the previous measures, and can also include pin placement, or the implementation of “system level” features such as HW Virtualization, micro kernels, Secure boot, Trusted Execution Environments… Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group states that "For chips with security features or functionality that may impact security it is important to understand where these are located on the chip’s pin out. It is generally advisable not to use chips where these features are on the outer two rows in high-security environments due to risk of fly wires being used". Some labs consider today that for "grid array" chip carriers, the outer three or four rows might be relatively easy to access for an attacker. In any case, a consensus is needed amongst stakeholders and security labs on this topic, so cybersecurity agencies could provide vendors with clear recommendations. The ease of access to the components, as well as their removability, can also be considered during the design phases, even if it cannot be the primary physical protection measure. see Symantec Insecurity in the Internet of things, March 12, 2015 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP I3 | Insecure Network Services See for example Symantec Insecurity in the Internet of things, March 12, 2015, IoT-A - D4.2 - Concepts and Solutions for Privacy and Security in the Resolution Infrastructure Providing a secure configuration by default means in practice that • a remote service will use HTTPS by default • setup processes include the necessary steps to upload any security configuration data such as certificates • the stronger password policies will be selected by default • … See The Internet of Fails: Where IoT Has Gone Wrong and How We're Making It Right and OWASP I10 | Poor Physical Security

text: December 2016

text: See A Primer on IoT Security Research, March 30 2015, Stanislav See OWASP I8 | Insufficient Security Configurability and See Security of Things: An Implementers’ Guide to Cyber- Security for Internet of Things Devices and Beyond, NCC group See Symantec Insecurity in the Internet of things, March 12, 2015 and The Internet of Fails Where IoT Has Gone Wrong and How We're Making It Right See Home Automation Benchmarking by SYNACK, or OWASP I3 | Insecure Network Services see Symantec Insecurity in the Internet of things, March 12, 2015 See for example Veracode White Paper – The Internet of Things: Security Research Study or Security of Things: An Implementers’ Guide to Cyber-Security for Internet of Things Devices and Beyond, NCC group See OWASP I10 | Poor Physical Security See https://en.wikipedia.org/wiki/DMA_attack See e.g. OWASP I10 | Poor Physical Security

identifier: Cyber Security and Resilience of smart cars

amnesord: Artificial Intelligence and Next Gen Technologies

title: Cyber Security and Resilience of smart cars

text: Cyber Security and Resilience of smart cars Good practices and recommendations DECEMBER 2016

text: About ENISA

text: The European Union Agency for Network and Information Security (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

text: Contact

text: For contacting the authors please use resilience@enisa.europa.eu. For media enquiries about this paper, please use press@enisa.europa.eu.

text: Acknowledgements

text: Over the course of this study, we have received valuable input and feedback from: Ami Dotan (Karamba Security) Andreas Bogk (HERE) Assaf Harel (Karamba Security) Aymen Boudguiga (IRT SystemX) Carsten Maple (University of Warwick) Christian Olt (Deutsche Telekom) Dario Castello (Fiat Chrysler Automobile Group) David Barzilai (Karamba Security) Eric Barenzung (EB Consulting) Erwan Broquaire (CEREMA) Evgeny Grigorenko (Kaspersky Lab) Florian Stosse (Bureau Veritas) Franck Sadmi (Bureau Veritas) Francois Terrot (Visteon Corporation) Frank Marescal (Gendarmerie Nationale-France) Gianmarco Baldini (Joint Research Center) Giovanni Rigazzi (University of Bristol) Guillaume Dufay (Prove & Run) Hari Sankar Ramakrishnan (RDW. Netherlands) Jacques Kunegel (ACTIA Automotive) Jan de Meer (smartspacelab.eu GmbH) Jan Muenther (HERE) Jasja Tijink (Kapsch TrafficCom AG) Joachim Lueken (Nokia Solutions and Networks) Josh Corman (I am the Cavalry (IATC)) Konstantinos Markantonakis (Royal Holloway University of London) Kostis Anagnostopoulos (Joint Research Center) Lutz Cleemann (Schweizer Akademie der technischen Wissenschaften – SATW) Magnus Gerisch (Capgemini Deutschland GmbH)

text: Markus Tschersich (Continental Teves AG & Co. oHG) Markus Ullmann (Federal Office for Information Security & University of Applied Sciences Bonn-Rhine-Sieg) Mathias Dehm (Continental Teves AG & Co. oHG) Mike Parris (SBD) Ole Hinrichs (Schindler Rechtsanwälte and Ole Hinrichs Datenschutzbeauftragter) Paul Labrogere (IRT SystemX) Philippe Robin (Technoveo) Pierre Schnarz (Continental Teves AG & Co. oHG) Pietro Ferrara (Julia S.R.L) Romain Crunelle (ELIOCITY) Sadio Ba (ANSSI) Sanjeet Kumar Pattnaik (RDW) Sergey Zorin (Kaspersky Lab) Tal Ben-David (Karamba Security) Teddy Zhai (INTEGRITY Security Service, Green Hills Software) Thomas Bitterlich (T-Systems) Thomas Born (Vodafone Automotive) Timo van Roermund (NXP Semiconductors) Vibhu Sharma (NXP Semiconductors) Wolfgang Rosenkranz (Kuratorium Sicheres Östereich) Finally we thank the experts of the ENISA Cars and Roads SECurity (CaRSEC) Expert Group and all participants to the ENISA validation workshop in Munich in October 2016 in providing us useful feedback during discussions and interviews.

text: Legal notice

text: Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the

text: Regulation (EU) No 526/2013

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time.

text: Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication.

text: This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

text: Copyright Notice

text: © European Union Agency for Network and Information Security (ENISA), 2016 Reproduction is authorised provided the source is acknowledged.

text: ISBN: 978-92-9204-184-7 | doi: 10.2824/87614

text: Contents

text: 1. Introduction 8

text: Objectives and scope 8

text: Methodology 9

text: EU Policy context 10

text: Target Audience 11

text: 1.4.1 Car Manufacturers 11 1.4.2 Tier-1 and Tier-2 suppliers 11 1.4.3 Aftermarket suppliers 12

text: Structure of this document 12

text: 2. Key aspects of the smart cars 13

text: Definition 13

text: Typical architecture and assets 14

text: 2.2.1 Powertrain control 16 2.2.2 Chassis control 18 2.2.3 Body control 18 2.2.4 Infotainment control 18 2.2.5 Communications control 19 2.2.6 Diagnostic and maintenance systems 22 2.2.7 Security, safety and privacy concerns 22

text: 3. Threats and risk analysis 24

text: Threats taxonomy 24

text: Attack potential 29

text: Sample cyber security attacks 30

text: Attack scenarios 33

text: 3.4.1 Remote attacks (threatening passengers safety) 33 3.4.2 Persistent vehicle alteration (by the legitimate user or by the use of diagnostic equipment)35 3.4.3 Theft 38 3.4.4 Surveillance 41

text: 4. Gap analysis and good practices 44

text: Gaps and challenges 44

text: 4.1.1 Insecure design or development 44 4.1.2 Liability 45 4.1.3 Safety and security process integration 46

text: Constraints and incentives 48

text: 4.2.1 Constraints 48 4.2.2 Incentives 49

text: Good practices 51

text: 4.3.1 Policy and standards 51 4.3.2 Organizational measures 52 4.3.3 Technical 53

text: 5. Recommendations 57

text: Criteria and processes 58

text: 6. Glossary and abbreviations 62

text: 7. Appendix A: Detailed risk ratings for the attack scenarios 64

text: 8. Appendix B: Detailed good practices 68

text: 8.1.1 Policy and standards 68 8.1.2 Organizational measures 68 8.1.3 Security functions 72

text: Executive Summary

text: In this report ENISA defines smart cars as systems providing connected, added-value features in order to enhance car users experience or improve car safety. It encompasses use cases such as telematics,

text: connected infotainment or intra-vehicular communication. The report excludes Car-to-car as well as autonomous vehicles as these technologies are not in use today. Practices discussed in this report concern not only passenger cars but also commercial vehicles (such as busses, coaches etc) and aim to map the current threats that passengers and drivers are exposed every day to. The goal is to secure smart cars today for safer autonomous cars tomorrow.

text: Over the last few years, there have been a number of publications on attacks targeting automotive systems, and in particular smart cars. An attack on a smart car would threaten the safety and privacy of passengers and other citizens. These threats are already having a big impact on car manufacturers, with millions of cars being recalled because of their vulnerability, not to mention the effects of the widespread media coverage of the issues.

text: The objective of this study is to identify good practices that ensure the security of smart cars against cyber threats, with the particularity that smart cars’ security shall also guarantee safety. The study lists the sensitive assets present in smart cars, as well as the corresponding threats, risks, mitigation factors and possible security measures to implement. To obtain this information, experts in the fields and areas related with smart cars were contacted to gather their know-how and expertise. These exchanges led to three categories of good practices: Policy and standards, Organizational measures, and Security functions.

text: The protection of smart cars depends on the protection of all systems involved (cloud services, applications, car components, maintenance and diagnostic tools, etc.). However, the challenge resides mostly today in the security of car components and aftermarket products, where security functions have to be implemented in spite of several kinds of limitations: for example, security requirements may conflict with safety requirements. Furthermore, the very large number of interfaces to secure may lead to planning and cost issues; eventually, the long life of cars may create the need for dedicated security requirements.

text: The impact of attacks on a smart car has far-reaching consequences in terms of safety. The risk to the driver, their passengers and other users of the road makes it a matter of national and European interest. For this purpose, the following recommendations have been developed:

text: Recommendations for smart car manufacturers, tiers and aftermarket vendors:

text:  Improve cyber security in smart cars. The industry actors should establish the good practices that effectively enhance the security of their products.  Improve information sharing amongst industry actors. Information sharing helps industry actors challenge the relevance of their security mechanisms according to field information. Communities for information sharing already exist, and we recommend pursuing this effort.  Improve exchanges with security researchers and third parties. Industry actors should enhance their contacts with third parties, especially from the security domain.

text: Recommendation for smart car manufacturers, tiers, aftermarket vendors and insurance companies:

text:  Clarify liability among industry actors. Living in heavily-tiered environment, industry actors should define processes to clarify their respective liability in case that security issues arise.

text: Recommendation for industry groups and associations:

text:  Achieve consensus on technical standards for good practices. The good practices listed in this report are meant as an input for a standardization effort, rather than being directly applicable to a specific car design. The details of the security requirements should be defined in the context of standards.  Define an independent third-party evaluation scheme. The existing safety standards for automotive systems only marginally address security, and we recommend to define an independent evaluation scheme.

text: Recommendation for industry groups and associations and security companies:

text:  Build tools for security analysis. Industry actors can directly improve their security testing skills by building tools for security testing and security monitoring.

text: 1. Introduction

text: Smart Cars integrate Internet of Things (IoT) components to bring added-value services to drivers and passengers. These components communicate with each other and with the outside of the car (other cars, external services).

text: Over the last few years, there have been many publications on attacks on automotive systems. A few of them have been particularly under the eye of media, resulting in reputational damage for car manufacturers, especially since several attacks were demonstrated as cheap and easy, as in the example of a teenager unlocking and starting remotely a connected car with only $15 of simple electronics gear.

text: Beside reputational damage, the cost of cyber security is becoming an issue for car manufacturers. In the past years, vulnerabilities were found and resulted in an ever increasing number of recalls:

text:  Charlie Miller and Chris Valasek made a spectacular proof-of-concept of remote attacks by taking control of a Jeep and sending it off-the-road , forcing 1.4 million cars to be recalled;  Security researchers hacked the BMW ConnectedDrive and managed to remotely unlock cars, with even more industrial impact than the Miller/Valasek hack (2.2 million cars had to be recalled);  More recently, even more vehicles (including most Volkswagen cars produced since 1995) have been shown vulnerable to an attack on remote keyless entry , thus once again increasing the size of impacted fleet. This last issue marked a steep progression of the number of potentially affected cars, which is in the order of magnitude of 100 million vehicles .

text: Yet another example is the recent hack of Tesla electric cars , requiring a software update for the car operating system.

text: These threats have impacts on the security, the safety and the privacy of the passengers and of other citizens.

text: The objective of this study is to identify the good practices to ensure the security of smart cars against cyber threats, with the particularity that Smart Cars security shall also guarantee safety.

text: Objectives and scope

text: This study presents an analysis of the current situation in smart cars and considers the key factors in play, including: how connectivity changed the security model of cars, how the heavily-tiered car ecosystem can manage these issues, and how can security be integrated in existing, safety-oriented, product lifecycles. Therefore, the following objectives have been set:  Review and analyse the architecture and interfaces of smart cars;

text:  Study the car ecosystem actors and lifecycles;  List the main threats applicable to smart cars;  Collect good security practices;  Analyse, in relation to the identified good security practices, gaps in current implementations;  Explore limiting factors, impairments, constraints and potential incentives for the target audience to deploy these measures.

text: Methodology

text: This study was carried out using a five-step methodology (shown in Figure 1) which begins at the initial information gathering from official sources and experts in the field and ends in the development of a report summarizing the findings and the recommendations to the target audience.

text: 1. Identification of experts: the first step was to identify the experts in the field of smart cars security.

text: In order to obtain varied and well-balanced results, experts were selected from Manufacturers, tier- 1 and tier-2 suppliers, aftermarket product suppliers, academics, and other actors, such as consulting companies, test and certification companies and governmental actors.

text: 2. Desktop Research: initial research of already published documents in order to get as much

text: information about communication dependencies as possible. This notably allowed to:  Identify the assets and threats specific to smart cars through desktop research and interviews with stakeholders in the smart cars domain;  Identify good practices to secure the critical assets (business and societal) from cyber threats  Analyse the most feared attack scenarios

text:  Present the good practices in a practical way by showing how to overcome the selected end-toend attack scenarios.

text: 3. Collection of experts and stakeholders point of view: we engaged stakeholders through interviews

text: to understand the current status of security and their challenges. For that purpose, we developed a questionnaire to understand the challenges and needs of car manufacturers and their suppliers;

text: 4. Analysis: the fourth step was to analyse all the data obtained, including the results of the interviews,

text: gathering initial conclusions.

text: 5. Conclusions and recommendations: the last step was to further analyse and contrast these results

text: with the experience of the consortium and external sources. The study was validated with the stakeholders, through a review phase and a face-to-face validation 8 9 workshop. We also stayed updated with regard to the C-ITS Platform run by DG MOVE , to synergize efforts. Moreover input from the CARSEC expert group was used to finalize the deliverable.

text: EU Policy context

text: From a regulation point of view, few initiatives are specific to smart cars:

text:  The European Parliament voted in 2015 to mandate the implementation of the eCall system in cars commercialized after April 2018;  More generally, since smart cars consist of cyber-physical components, they are concerned by: 12 13  The General Data Protection Regulation , replacing the Data Protection Directive ;  The Network and Information Security Directive (NIS) , which will have an impact on cloud services that may be associated with smart car components. Other initiatives have been launched, independently from these regulations. In particular, the EU Commission launched the AIOTI Alliance in 2015, in order to enhance the dialogue between actors of the Internet of Things (IoT). An AIOTI workgroup is specifically dedicated to Smart Mobility, which includes IoT use cases pertaining to the car industry.

text: A 2015 report from the AIOTI Smart Mobility workgroup may be used as an introduction to other initiatives in Europe on this topic:

text:  The European Technology Platform for Road Transport Research (ERTRAC)  Research and Development initiatives funded via Horizon 2020  The C-ITS Deployment Platform  The Electronic Components and Systems for European Leadership (ECSEL)  The Important Project of Common European Interest (IPCEI)  Main standards developing Standards Developing Organizations (SDOs), alliances & open source initiatives  FIWARE  An exploration of national or company initiatives

text: While most of them are strongly related to autonomous driving, several have to take into account cybersecurity issues already present in today’s cars.

text: Target Audience

text: This report provides information on smart cars’ security including lifecycle (including the security maintenance in the field) and business perspective (not focusing only on technical measures). Therefore, the

text: target audience is mostly Car manufacturers, Tier 1 and Tier 2 suppliers, and Aftermarket suppliers.

text: 1.4.1 Car Manufacturers

text: Car manufacturers design new cars and select their equipment according to marketing considerations. Regarding manufacturing of the car itself, their role is mainly limited to the assembly of the various car components provided by their suppliers. They provide to their supplier functional, safety and security requirements for the components as well as qualification of the products.

text: They also have to take into account security, safety and privacy by design, especially since aftermarket components may be added to the vehicle later by the user.

text: 1.4.2 Tier-1 and Tier-2 suppliers

text: Car manufacturing is a heavily tiered ecosystem. Car manufacturers integrate components provided by suppliers, which are labelled as “Tier-1”. While driving systems are usually a prerogative of the manufacturer itself, Tier-1 suppliers may be in charge of manufacturing most of the components directly facing the final user. From entertainment systems to car seats, a large part of the car cost may be associated to components manufactured by Tier-1 suppliers.

text: While Tier-1 suppliers have direct contractual relationships with car manufacturers to provide car components, the ecosystem also includes suppliers labelled as “Tier-2”. Tier-2 suppliers only have contractual relationships with Tier-1 suppliers. They produce, for example, plastics, mechanical parts, molds, electronic components or software.

text: Also some Tier-2 suppliers may also become Tier-1, for instance Operating System (OS) providers for the multimedia system have direct contact with the car manufacturer to allow more control, customization or monetization on the applications, or also secure components providers in order to propose personalization or Over The Air (OTA) management services.

text: In some cases, the design of one single component may be shared between several parties. For example, concerning a telematics platform, its hardware and operating system may be designed and manufactured by a Tier-1 supplier, while the software application may be designed and uploaded by the car manufacturer.

text: 1.4.3 Aftermarket suppliers

text: Customers can also buy aftermarket products from other vendors; for example smart dongles used on the OBD-II port, providing additional features to their car. More traditional aftermarket products may include media players or third-party GNSS.

text: Structure of this document

text: This document contains the following sections:

text:  Key aspects of the smart cars. This section details the typical architectures found in smart cars, as well as the relationships between main actors of the ecosystem. It eventually lists the sensitive assets of smart cars;  Threats. This section elaborates on the assets by listing the main threats on smart cars. Sample attacks taken from the state-of-the-art are given as illustration of the way these threats can lead to car compromising. Eventually, a few significant attacks are further detailed into Attack scenarios, to clarify the different steps necessary for an attack, as well as the expected attack potential required for such attack;  Key findings. This section describes the good practices able to mitigate the aforementioned attacks. It also puts these good practices in perspectives by describing the current gaps and challenges for their implementation, as well as the constraints and incentives for the actors of the ecosystem;  Recommendations intended to overcome gaps and challenges in the implementation of good practices;  Glossary and abbreviations

text: Further details are given in appendix:  Appendix A details the calculation of attack potentials used in the attack scenarios,  Appendix B gives further details on the good practices.

text: 2. Key aspects of the smart cars

text: Definition

text: In this study, we define Smart Cars as systems providing connected, added-value features in order to

text: enhance car users’ experience or improve car safety. It encompasses use cases such as telematics, connected

text: infotainment or intra-vehicular communication. Practices discussed in this report concern not only passenger cars but also commercial vehicles (such as busses, coaches etc) and aim to map the current threats that passengers and drivers are exposed every day to.

text: Even if different definitions of smart, connected cars can be found in the literature, no official all-accepted definition exists. Here a indicative overview of the different definition so far: a first effort to define different levels of automation for on-road vehicles is done in SAE J3016. Figure 2 illustrates the different levels of automation for on road vehicles, as defined in SAE J3016. This study covers vehicles belonging to levels 1 to 3.

text: Another definition comes from the Amsterdam declaration which make a distinction between connected cars (including cooperative driving: communication between vehicles and also with the infrastructure (C- ITS)) and automated driving (referring to the capability of a vehicle to operate and manoeuvre independently in real traffic situations, using on-board sensors, cameras, associated software, and maps in order to detect its surroundings). Following this definition, only connected cars are taken into account in the context of this study.

text: This study excludes car-to-car as well as autonomous vehicles as these technologies are not in use today. V2X interfaces are not taken into account in this report (in the sense of analysing their vulnerabilities or defining explicit countermeasures), however the existence of V2X interfaces will be taken into account, whenever it has an impact on the assets or threats to be considered.

text: The study encompasses use cases such as:  Telematics, used for example in the context of fleet management or geo-fencing;  Connected infotainment, which provides an integrated multimedia offer with potential added value services (such as the access to an application store) and can access driving information (such as speed) as well as control non-essential functions (such as air conditioning);  Intra-vehicular communication, where the infotainment connections can be shared with user devices, typically by creating a hotspot within the vehicle.

text: Typical architecture and assets

text: We describe in this section the typical architecture of smart cars, and list the assets that can be distinguished within such architectures. The architecture of subnetworks and protocols may vary from a vehicle to another, therefore Figure 3 provides a high-level overview of such systems.

text: Most car architectures distinguish between different domains, interconnected by a central gateway, as shown in Figure 3. Domains correspond to different, or sometimes independent, features of the car. All these components may cause risks, should they be compromised. The impact of these risks may vary between safety, security or privacy concerns. For this reason, components of a smart car are described as assets and require appropriate protection. Figure 4 hereafter lists a number of these assets. More details concerning these assets, as well as some logical assets (Section 2.2.7), are given in the following sections.

text: We distinguish the components according to the following categories:

text:  Powertrain control  Chassis control  Body control  Infotainment control  Communications control  Diagnostic and maintenance systems

text: 2.2.1 Powertrain control

text: This domain is in charge of the chain between the energy source of the car and its transformation into propulsion.

text: ECUs and sensors

text: Modern cars are composed of many embedded Electronic Control Units (ECU) that control mechanical or electronic systems of the vehicle . While ECUs are different from one domain to another, here are a few general explanations on the architecture of ECUs and TCUs (Telematics Control Units):

text:  As other IoT systems, automotive devices often rely on the ARM platform for application processors (other available architectures are Power, SH, V850, and TriCore) . Processors for other usage may come from many origins. However, due to the constrained operating environment in automotive environments (temperature, humidity, lifetime), specific declinations of processors, not commercialgrade but automotive-grade, are used.  For increasing security, and in particular for vehicular communications, these systems may also rely on a Trusted Platform Module (TPM), a smart card core or a Hardware Security Module (HSM) .  ECU/TCU applications may be written directly in assembly or rely on a specialized real-time operating system, such as VxWorks (Wind River Systems), Integrity (Green Hills Software), or AUTOSAR.

text: Subnetwork

text: The powertrain subnetwork typically relies on the Controller Area Network (CAN) protocol.

text: CAN , an ISO standard since 1993, is by far the most well-known and popular bus, to which most of the ECUs of the vehicles are connected. There may be several CAN buses in a vehicle, interconnected by a gateway, to isolate the most critical functions (such as powertrain management) from the less critical (such as multimedia). The traffic on this internal network varies from one solution to another; in some instances the network can support several hundreds of messages per second; the CAN bus is a prominent example and has been thoroughly studied by many researchers .

text: CANs, as with other protocols described in this report, face issues related to bandwidth, scalability or security; protocols such as Ethernet , introduced in 2008, are, today, still limited to a subpart of the network (multimedia, assisted driving…).

text: The FlexRey protocol (ISO 17458) is also being put in use starting from 2008.

text: Other components

text: This domain includes physical systems such as internal combustion or electrical engines, as well as the transmission, drive shafts, and wheels.

text: 2.2.2 Chassis control

text: This domain is in charge of the control of the vehicle frame with regard to its environment.

text: ECUs and sensors

text: ECUs are similar to those found in the powertrain domains (see Section 2.2.1). They allow the control of functions such as steering control, airbag control, braking systems, or Advanced Driver Assistance Systems (ADAS).

text: Subnetwork

text: The subnetwork typically relies on the CAN protocol (see Section 2.2.1), but also on protocols such as FlexRay, or RF (e.g. for Tire Pressure Monitoring Systems). FlexRay, introduced in 2008, is faster than CAN and designed for drive-by-wire applications which substitutes usual mechanical functions with software. .

text: Other components

text: This typically includes the steering and brakes, but also airbag, embedded cameras, rear-view mirrors, or even windshield wipers.

text: 2.2.3 Body control

text: The body control is in charge of the body, which means most of the time the passenger’s compartment and trunk.

text: ECUs and sensors

text: ECUs are similar to those found in the powertrain domains (see Section 2.2.1). They allow passengers to control various functions such as instrument cluster, climate control, or door locking.

text: Subnetwork

text: The subnetwork typically relies on the CAN (see Section 2.2.1), LIN/SAE J2602 (for door lock, air conditioning, seat belts…), or RF protocols (Keyless/passive entry systems). LIN, a value-oriented variant of CAN introduced in 2002, is based on a single wire, has simpler controllers and offers lower bandwidth.

text: Other components

text: This typically includes the dashboard display, air conditioning, but also the lights, direction or warning lights, the doors, windows, seat belts, and even motorized or heating seats.

text: 2.2.4 Infotainment control

text: This domain is generally separated from the remainder of the body. It includes navigation services, communications (telephone, etc.) as well as entertainment services (head unit audio/video).

text: ECUs and sensors

text: ECUs are similar to those found in the powertrain domains (see Section 2.2.1). They allow passengers to control various functions such as the Head unit for audio/video content, but also navigation, or interactions with the user’s telephone. Services offered through this domain can vary greatly, for example:

text:  Entertainment services (audio/video)  Internet access  Driving services such as traffic information, maps...  Additional services such as fleet management, digital tachograph, geo-fencing... These services cause infotainment ECUs to sometimes have specific architectures: - For infotainment systems, operating systems from the mobile industry may also be used in ECUs (Windows CE (phased out), Android, Tizen or WebOS) - QNX is also used in systems dedicated to the integration of users’ smartphones into the vehicle systems. For example, it is used in Apple Carplay and Android Auto technologies, which allows the end-user to get the display of a mobile phone mirrored to the infotainment display, and grant him access to its mobile applications. - Automotive Grade Linux (AGL) and Linux Genivi are two open-source projects aimed to create software solutions for automotive applications.

text: Subnetwork

text: The subnetwork typically relies on protocols such as MOST, but also on ad-hoc networks using Bluetooth or Wi-Fi. Infotainment systems rely on wireless connectivity provided either by an embedded UICC or by an end-user device (smartphone) connected by Bluetooth or with a USB cable. In addition, Ethernet can be used to connect camera systems.

text: Other components

text: External media that are directly connected to the infotainment components, such as drives or phones, should also be considered as an asset.

text: 2.2.5 Communications control

text: This domain, contrarily to the previous ones, is not a subnetwork, but more frequently a set of communication features offered by a Telematics control unit (TCU), acting as a gateway.

text: Gateways ECUs with Telematics and communications

text: The gateway provides both the connectivity and most of the security protections intended for the communications (firewalling, authentication features…). It collects data from the various ECUs using one of the vehicle data buses and provides Internet remote connectivity through an embedded GSM module or using driver’s smartphone for instance. This unit is generally also coupled with a GNSS to obtain vehicle positioning information. A number of use-cases that are leveraging TCU connectivity are:

text:  Remote diagnostic (e.g. failure notifications, updating ECU SW/FW or ECU parameters)  Remote transmission of vehicle data  Crash reporting and emergency warning (eCall, that will be mandatory in Europe in 2018)  Stolen vehicle tracking or geo-fencing  Remote engine start

text:  Fleet management, for instance for rental car companies (for example for trip tracking or diagnosis)  Insurance, for pay-as-you-drive insurance plans  “smart driving assistant” (e.g. for fuel efficiency or to improve driving habits)  Inform driver on the battery State of Charge (SoC) for Electric Vehicles (EV)  Eco-driving  Big Data applications

text: External communication networks

text: The TCU typically provides 3G or Wi-Fi connectivity to provide several kinds of services, for example eCall, but also V2X communication . Other protocols are possible, as shown in Figure 5 hereafter, which gives an example of external interfaces found in a smart car. These typically include interfaces intended for long range communication, as well as wired or wireless interfaces intended for local use.

text: Besides wired protocols such as USB or diagnostics, TCUs often provide various wireless protocols, as detailed hereafter.

text: Long-range wireless protocols

text: Telematics also rely on wireless connectivity provided either by a directly embedded UICC or the driver’s cell phone. Mobile protocols such as GSM/GPRS/3G/4G/UMTS/LTE may be used in a variety of contexts, but the most prominent are the eCall service and the capacity of providing OTA updates to car component firmware. Smart cars also use GNSS as part of their localization features. Protocols (such as LoRa and SIGFOX) used nowadays for IoT protocols solutions could also be used by automobile in the future.

text: Intra-vehicle wireless protocols

text: Bluetooth and Wi-Fi are frequently provided as a protocol of choice for intra-vehicular communication, although the state-of-the-art suggests possible alternatives, such as ZigBee, Passive RFID, UWB or 60 GHz mm Wave . Usually, communication costs for the TCU are supported by the car manufacturer, whereas they are supported by the end-user for the infotainment. Wireless protocols are also used in two different contexts:

text:  Near-range to relatively long-range protocols can be used for communication with sensors, for example DASH7, used for Tire Pressure Monitoring Systems (TPMS)  Wi-Fi or Bluetooth connection may be used, but mostly to communicate with smartphones, using dedicated protocols . The next type of components to benefit from such interfaces to the vehicles seems to be wearables and smart home devices . Such effort is already started in the context of the Open Connectivity foundation project .

text: Inter-vehicle, or Vehicle-to-infrastructure wireless protocols

text: Inter-vehicle communications use a specific band allocated for ITS communication (5.9 GHz Band, called DSRC). Such communications typically use protocols such as

text:  WAVE (Wireless Access in Vehicular Environments), which is a mode of operation used by IEEE 802.11compliant devices to operate in the DSRC band;  DSRC (Dedicated Short Range Communications), not to be mistaken with the DSRC Band, which is a standard based on IEEE 802.11a;  IEEE 802.11p, which is based on the same ASTM Standard E2213-03 as DSRC.

text: Protection of communication typically relies on a PKI deployed specifically for this purpose. Work in the European Union on this matter is coordinated under the Connected and automated driving (C-ITS) deployment platform , which aims at harmonizing the PKI and trust model for the European Union.

text: Other components

text: 2.2.6 Diagnostic and maintenance systems

text: Diagnostic and maintenance systems are external systems interfaced with the car through a dedicated port. We also include aftermarket dongles in this category, since they use the same interfaces. It should however be noted that they do not necessarily provide maintenance or diagnostic features.

text: OBD II ports and Garage or maintenance equipment

text: Various maintenance and diagnostic equipment can be plugged on cars via the OBD-II ports. They can be standalone equipment, such as portable data collectors, or comprised of applications running on a PC or tablet.

text: Aftermarket dongles

text: Aftermarket telematics components such as "smart dongles" also have OBD-II connectivity, as well as external Bluetooth or cellular connectivity. They are often built upon the same set of components as the competition (SoC, sensor packages, CAN transceiver chip...). They may also include debugging interfaces (for example via mini-USB), configured to emulate a network adapter (i.e., once connected, the TCU appears as a device on the network).

text: Diagnostic subnetwork

text: The subnetwork diagnostic is usually performed directly on the CAN bus (see section 2.2.1), through the OBD-II port. Ethernet is also about to be used for diagnostics over the DoIP protocol (Diagnostic over IP).

text: 2.2.7 Security, safety and privacy concerns

text: Assets are related to safety in several ways:

text:  Compromising powertrain or chassis ECUs and networks may obviously cause a vehicle to behave in an unexpected way, for example if an attacker illegitimately compromises ignition, steering, brakes, speed and gear control, or driving support (such as ABS);  Compromising body ECUs and networks systems that may increase harm to the passengers, should they malfunction:  airbag or safety belts,  door force-lock used for child protection,  the windshield wipers,  alerts in the vehicle, dashboard display, notably speed, collision or lane departure warning...  air conditioning,  motorized or heating seats,  automatic trunk closing,  rear-view mirrors as well as automated windows or roof...

text: The OBD-II interface is also called a “diagnostics plug”, and is available on all vehicles sold in Europe since 2001).

text: These systems may also cause a disturbance on surrounding vehicles, for example if there is a disruption of headlights or of direction/warning lights;  Infotainment ECUs and networks may also cause safety issues : incorrect navigation data may lead the car to unsafe areas, and a disturbance of the audio in the entertainment system (such as high volume burst) may distract the driver

text: More specifically, the networks of the car can be specifically targeted and cause the same safety risks:

text:  Internal networks (for example the CAN bus, but it also includes wireless networks such as Tire Pressure Monitoring Systems (TPMS)): a disruption or integrity breach on these networks may result in a loss of control of a vehicle;  Cellular connection of the car may also have adverse impacts on safety, for example in the case of a spoofed firmware update triggered by SMS;  Local network (e.g. Wi-Fi, BT) and connection to user phones theoretically leads only to the entertainment components of the vehicle. But as the study shows, the lack of isolation between entertainment and driving systems might result in safety-related vulnerabilities from these entry points. This reasoning might also be extended to other local connections such as a wireless keyfob;  V2X communications, which could lead to accidents, were they disrupted or spoofed ;  The disruption of eCall, or other alert or alarms, may eventually cause additional concerns at an accident scene.

text: Additional security concerns are found in several ways:

text:  An attacker may get an unauthorized access to functions not intended for users (fleet management,

text: digital tachograph, geo-fencing...). This typically evokes fraud situations, but this may also cause the

text: vehicle systems to malfunction and cause hazardous situations following drivers’ disruption;  Trade secrets may be at risk in several systems: TCU/ECU firmware, which might be sensitive with regard to the competition. Some industry actors, in particular, may be wary of the possibility of device cloning (for example the cloning of aftermarket products);  More generally, intellectual property may also be threatened: Smart car applications, or infotainment application or media, which might be sensitive with regard to fraud (use of application copies obtained through unofficial stores, unauthorized copies of paid premium content…)  Features or functions implemented using multiple components (such as ADAS) can augment risk in a system if they are not correctly integrated in it.

text: Data confidentiality and privacy are eventually at risk as well. For example, compromising embedded cameras may lead to privacy issues for the driver and passengers.

text: 3. Threats and risk analysis

text: Threats taxonomy

text: This study builds upon the threats described in ENISA’s previous work . This set of threats has been compared with other available threat analysis during the stocktaking phase of this study. While the presentation and categories of threats differ from analysis to analysis, the outcome of this comparison showed that the content remains the same, that nearly all threats found in ENISA’s report are retained. The list of threats was discussed with experts during the interview phase, to focus on a restricted group of significant threats, as shown in Figure 6:

text: Below the list of threats and assets affected:

text: Attack potential

text: This study chooses not to define any specific threat agents (script kiddies, government agencies…) except when it gives useful information on the attacker motivation. Instead, the study will focus on the notion of attack potential, meaning the potential of someone to perform an attack. Attack potential is described in the Common Criteria and further refined in the Common Criteria Evaluation Methodology . In Common Criteria, a product evaluated to achieve a given assurance level is supposed to resist attackers with a predetermined attack potential. During the vulnerability assessment, if evaluators detect a potential vulnerability, they will calculate the attack potential required to exploit such a vulnerability. If the attack is exploitable with a potential lower than what

text: the product is expected to resist, the product will fail the associated evaluation task. This attack potential is typically built upon several measures or estimations:

text:  Time taken to identify and exploit;  Specialist technical expertise required;  Knowledge of the [product] design and operation;  Window of opportunity;  IT hardware/software or other equipment required for exploitation.

text: In practice, this means that an evaluated product may be vulnerable to some attacks, but that these attacks require more expertise (or resources, or motivation) than the targeted resistance can handle. For example, Common Criteria certificates follow a scale of EAL (Evaluation Assurance Level) where a higher EAL means, through the AVA_VAN assurance requirements, that the product is expected to resist stronger attackers:

text:  A hardware product at an EAL2 level may resist to script kiddies using simple software exploitation frameworks  The same product evaluated at EAL4+ may be expected to resist an attack by experts using sophisticated equipment such as lasers or Focused Ion Beams.

text: When performing a threat assessment prior to a certification, computing an attack potential for a threat will help decide:

text:  Which certification level may provide assurance that the threat is covered;  Whether some attack scenarios will be “too strong” to be addressed by the expected certification.

text: A separate issue for computing the attack potential may be that some of the estimating measures dominate the others. A good example is the 2014 Jeep hack by Miller and Valasek where a lot of time was required to identify the vulnerability (the DBus daemon), while exploiting it did not require any special expertise or equipment.

text: Note also that, in practice, the attack potential of attackers increases over time, as they gain more expertise and knowledge of the automotive systems as well as they build more sophisticated tools. Moreover, the potential of attackers can sometimes grow rapidly: for. For instance, when a skilled hacker publishes a vulnerability, including hints on how to exploit it, (and even scripts for automated attacks), less skilled persons (like script kiddies) may have sufficient attack potential to repeat or further exploit this same vulnerability. While this study will not try to calculate an accurate attack potential for the attack scenarios hereafter, it aims at giving a hint at the differences of potential required depending on the scenario. This is also intended to be a hint to future certification efforts.

text: Sample cyber security attacks

text: The Table 2 hereafter lists a sample of attacks showing how previous threats can be related to existing research and exploitation paths:

text: Attack scenarios

text: The threats described previously give a very high-level view of the potential issues facing smart cars. Some examples of attacks scenarios are introduced hereafter to show in more details the variety of attacks that can potentially target smart cars. Additionally, they provide an introduction to the categories of good practices allowing to cover these threats. We consider several categories

text: of attacks, which are described as scenarios hereafter: Remote attacks, Persistent vehicle alteration, Theft and Surveillance. These scenarios are detailed in the next sections. (More details

text: concerning the risk rating can be found in Section 7 – Appendix A).

text: 3.4.1 Remote attacks (threatening passengers safety)

text: This kind of attack is very much in the public eye . While the attack is not at all trivial to realize, and therefore rated as “unlikely”, it can have devastating consequences.

text: The type of attacks described by this scenario could be roughly described as in the Figure 7 hereafter :

text: Example: As a first step, the attacker may know that a given vehicle model has a vulnerable SMS (Single Messaging System) link, and knowing its MSIN, enumerates MSINs in hope that all numbers have been sequentially assigned, thus discovering other vulnerable vehicles .

text:  The cost to identify such a vulnerability is only relatively high, because the attack surface of a smart car is very large: if the direct IP connectivity of a car is well-protected, the attacker can move to another entry point such as SMS.  Interestingly, the use of dedicated components to compromise cellular connection (“stingrays” or “fake BTS”) was studied but is dismissed by newer studies describing it as an unnecessary complex entry point compared to other methods, especially internet-based attacks .  As a second step, they exploit the lack of authentication for SMS update, and upload a crafted firmware to the TCU .  This is an extreme example: the attacker will typically gain an access of some sort on a TCU. The usefulness of this access will however be different depending on whether it consists in a simple

text: session, a highly privileged session, or the capacity to update a malicious firmware; which has consequences on what is possible in the third and last step.  As a last step, their crafted firmware is able to communicate legitimately on the CAN bus, allowing to communicate with the driving systems  The range of consequences may vary from the mildly disruptive (such as horn activation) to lifethreatening situations, such as brake disconnect, engine halt or air bag activation. Exploiting the complete scenario will require several vulnerabilities to be exploited in sequence, and should not be regarded as an easy task. In particular, sending crafted messages on the CAN bus is not a trivial way to trick an ECU into performing a malicious action . Note also that the attack can come from “unlikely” sources such as Digital Audio Broadcasting (DAB) radio receivers or the vehicle FM Radio Data System .

text: 3.4.2 Persistent vehicle alteration (by the legitimate user or by the use of diagnostic equipment)

text: This category includes for example cases where the legitimate user tries to modify the behaviour of their vehicle, as summarized in Figure 8. This may include:

text:  Attempts to “tune” the vehicle driving characteristics, for example to enhance performance. The car hacker’s handbook, for example, is advertised to users as mean to perform “car mods” or “discover undocumented features” ;

text:  Attempt to bypass monitoring services such as geo-fencing or fleet management. This is analogous to 76 77 existing situations such as tachograph fraud , although it is an extension of the existing situation, because tachograph fraud is clearly not part of geo-fencing or fleet management.

text: Other attackers than the legitimate user of the car may also want to alter the behaviour of the vehicle. For example, the attacker may be a garage employee using diagnostic equipment:

text:  Attacks in garages may be related to business intelligence (aiming at gaining sensible information on competitors technical implementations)  Attacks inside or outside garages may be related to organized crime. This may for example be used as a threat on the garage or users (on the model of ransomware). As for today, the presence of financial incentives is not yet very frequent (for example payment information accessible in entertainment systems). This example looks very much like existing scenarios targeting point-of-sale terminals, where malware such as memory scrapers can be installed by employees. The situation is however slightly different in garages, since:  The turnover in garages is not the same as large shopping centres that heavily rely on temporary work; this creates less opportunity for attackers;  The incentive in point of sale is not as strong (attacks on points-of-sale directly allow to obtain payment-enabling data)

text: Main scenario

text:  Example 1: The attacker connects to the CAN bus, for example by identifying the appropriate pins on the OBD II port. They may then plug a cheap CAN sniffer on these pins (step 1). The step 2 will consist in trying to analyse the CAN traffic and then alter the car behaviour via crafted packets (the car hacker’s handbook gives the example of a spoofed speed transmitted to the digital tachograph )  Example 2: As a first step, an attacker directly connects an ECU (using a JTAG port on the board). The step 2 will consist in exploiting the JTAG debug capacities by uploading a crafted firmware ;  Other examples of attacks may consist in glitching, memory dump …

text: Alternate scenario

text:  Example 1bis: As a first step, the attacker may buy a piece of black market diagnostic equipment , or reverse engineer a legitimate piece of equipment, or even access a legitimate piece of equipment (rogue garage employee). The second step may then consist in modifying an ECU by injecting a crafted firmware, or simply a previous, vulnerable version of the firmware.  Example 2: Instead of trying to access the diagnostic equipment itself, the attacker may try to compromise the laptop that interfaces with this equipment . In that case the skills may not be much more than being able to reverse a DLL and exploiting bad digital signature implementations, which are skills frequently found in “black hat” communities related to DRM, point-of-sale, malware creation... Even in that case, the attacker may need car-specific skills, for example to be able to craft a working firmware. This also assumes that the attacker will perform their attack remotely through a malware, which makes the whole attack more difficult by an order of magnitude.

text: 3.4.3 Theft

text: In this scenario we consider the possibility for an attacker to gain physical access to the inside of a vehicle without a legitimate access means.

text: Standard key fobs and access control devices usually work under the assumption that there is only one level of access, thus gaining access to the inside of a vehicle often entails access to the vehicle main functions : engine start, infotainment unit, trunk opening. While the most plausible risk is the plain and simple theft of the vehicle or any of the owner’s possessions kept inside, such an attack may be a first step towards a more involved attack scenario since access to the inside of the vehicle provides :

text:  Access to the OBD-II diagnostic port, thus easier access to the CAN/LIN bus;  Access to the head-up unit physical interfaces (USB, CD/DVD) and assets (navigation data, personal data, access to remote services);  Easier access to other ECUs (telematics control unit, engine / transmission control unit, gateway). A complex scenario may involve an attacker that uses one of the means listed above in order to incapacitate (fully or partially) the vehicle operation in such a way that only him/her can restore it remotely, and ask for a ransom. In such a case the main issue is the reproducibility, since such an attack would only be profitable if it has the potential to scale up.

text: The scenario can use very different approaches, such as:

text:  Compromising a local wireless connection (a proof of concept already exists),, where an insecure Wi-Fi connection could be used to ultimately disable the theft alarm )  Key fob cloning: the following techniques may provide this capability:  gain access to the key fob secure memory (through reverse engineering or side-channel);  compromise the pairing process, for instance by compromising the device used for pairing in the garage;  Use a known vulnerability to get hold of the unique ID from the car’s diagnostic port .  Relay attack: this attack has been shown to be effective with PKES (Passive Key Entry and Start) 8687 systems , where no other action than proximity is required on behalf of the user to open / ignite the car. In such a case it is possible to relay the near-field radio signal over large distances using cheap hardware, from the vehicle to the key fob. This requires the ability to place a radio transceiver near the key fob. The attack can only be effective if the security mechanism does not change the keys in time or if it uses a repeated set of security messages.  Rolling code jam: Even if the key cloning scenario is not feasible (by lack of the specific hardware used for pairing the key with the vehicle or reverse engineering / side channel capabilities), it is possible to compromise the rolling code by jamming the radio signal so that the code is not discarded by the vehicle and can be replayed. This attack requires cheap hardware and has been successfully demonstrated for a range of vehicles on the field .  Keyless systems: The smartphone application that controls the opening of the car is compromised, in order to gain illegitimate access to a car. While this mode of access control is far from being common, it may be in a near future , which will have the effect of overextending the attack surface with all mobile (applications and OS) vulnerabilities.

text: Many vulnerabilities used in such attacks are not as technically challenging as in other scenarios, and may use cheap and easy to come by devices that require no high level technical skills for their operation. In some cases, though, cryptographic attacks are needed to circumvent the keyless entry protection. Due to hardware limitation, these cryptographic protocols are however weaker than in many other domains, and researchers have shown that attacks can be performed without expensive equipment .

text: 3.4.4 Surveillance

text: This scenario gathers considerations regarding the possibilities of surveillance offered by recent cars and vehicles. With the exception of the effort of ETSI on the use of pseudonyms to avoid tracking , there is little published evidence or work for this kind of situations, several potential vulnerabilities and weaknesses have been noticed by proofs of concept by researchers .

text: There are essentially two kinds of plausible surveillance scenarios:

text:  Targeted surveillance, where a single individual is tracked using a vulnerability in its vehicle systems  Mass surveillance, where a large number of individuals are tracked through some common vulnerability.

text: An alternative to both scenarios consist in performing surveillance only on cloud-stored data, instead of focusing on vehicles. This alternative will not be explored in detail here, since ENISA already addressed the issue of cloud security .

text: In the case of targeted surveillance the high investment (in cost and risk) of the attack hints at the following plausible motives: espionage, crime, terrorism, or business intelligence. On the other hand the mass surveillance case involves spying on a large number of vehicles in order to get exploitable data. While there is not public record of such an exploitation (except for researchers’ demonstrations in limited scenarios), it is in principle possible to setup such a system to passively sniff the RF emissions of the vehicles and discriminate between them using unique identifiers.

text: The associated threat agents may thus be government agencies and criminal organisations, with a high attack potential and strong incentives for targeted surveillance, whereas the scope may be broader for mass surveillance due to the relative easiness of the underlying attacks

text: Typical attack vectors for targeted surveillance rely on modification of the vehicle software and/or hardware in order to setup the surveillance. Software-based scenarios could typically be found in cases where the attacker has no physical access to the targeted vehicle (therefore is unable to put a physical tracker in the vehicle).

text: The relevant vulnerable components are then the ECU hardware and software (mainly the infotainment system and navigation unit).

text: The typical attack vectors for mass surveillance are:

text:  All wireless emissions: Wi-Fi, Bluetooth and GSM/3G/4G signals can be used to uniquely identify a vehicle. In particular:  When the infotainment system provides a Wi-Fi hotspot functionality that broadcasts its SSID;  Most TPMS systems, when they are active, broadcast a unique RFID identifier;  Using a fake BTS, it is possible to spy on the ICCID of the USIM cards.  Car systems can allow fingerprinting , quite the same way as browser or device fingerprinting. However, it may be argued that the browser of an infotainment system allows an easier fingerprinting than sensors, which are more difficult to access.  Cloud storages / backed systems, which collect the position of a large set of vehicles. These includes the fleet management systems, localisation-aware services, and navigation systems real-time databases.

text: Depending on the scenario, the impacts are either financial, or on the privacy personal freedom of the individuals.

text: It should be noted that surveillance scenarios are facilitated by existing, user-accepted, monitoring features. Several examples come to mind, amongst which:

text:  The usage of OBD-II dongles to monitor driving habits in exchange of reduced assurance fees ;  The accumulation of private information due to the interconnection with social networks. These user-accepted usages come with entry points, some of them privileged (for example OBD-II dongles), which can be compromised by an attacker. Therefore, reducing the chance of privacy attacks could also benefit from limiting the user-accepted surveillance solutions. European privacy regulation already contributes to limit potential accumulation of private data and abuses of opt-out scenarios - however, they do not address the security risks caused by the introduction of technical components dedicated to user-data collection.

text: 4. Gap analysis and good practices

text: Gaps and challenges 4.1.1 Insecure design or development Insecure development in today’s cars

text: While the automotive industry has a long-standing expertise in car safety, security issues of connected systems in cars and their potential impact on car safety are not yet properly taken into account, except for few of them . Some studies tried to define a shortlist of the more frequent security issues found amongst 99 100 101 102 103 manufacturers . After having double checked these shortlists during our own interviews, the following issues seem indeed significant:

text:  No defence in depth strategy during the design of the system (such as a secure boot process, isolation of a Trusted Computing Base, limitation of the number of open ports, self-protection, …);  No security- or privacy-by-design. For example, telematics schemes may require the car maker to send most of the information exchanged on the CAN bus to a third-party, such as vehicle speed, throttle position, coolant and oil temperature, engine revision status, etc. More information than really needed may be exported outside of the car. While some actors are aware that private data should not be exported without a reason, the same line of reasoning is not always applied to sensitive data;  Lack of communication protection, on internal as well as external interfaces;  Lack of authentication and authorization, especially for privileged access to ECUs; for example:  no validation or signing of firmware updates,  updates happen without server authentication, and even on an arbitrary server,  no secure boot,  no cellular authentication, or weak authentication mechanisms, or failure to use components that provide authentication functions…,  no cryptographic keys distributed to garages;  Lack of hardening, for example:  No data execution prevention or attack mitigation technologies are used on firmware,  Public vulnerabilities (DNS proxy, http service...) are left unfixed,  ECU services are exposed through different entry points, and even unnecessary communication ports are left open; services such as telnet, web or SSH are sometimes bound to all network interfaces,  Weak passwords policies,  Misconfiguration (e.g. VPN) …  Lack of diagnosis / response capabilities

text: Security culture

text: Several sources highlight that actors of the smart car ecosystem come from different domains, leading to different approaches to security, for example that actors having a “deep software experience” are more likely to welcome features such as OTA updates, collaboration with "white hats" or the implementation of bug bounty programs .

text: As already stated, a transparent dialog with security researchers is needed to ensure that the whole community is in a “responsible” disclosure process. The current situation in automotive is very far from this situation, as

text:  Some findings have been left unpublished due to legal actions between manufacturers and researchers , leaving exploitable vulnerabilities in the wild during as long as two years; 107 108  Other researchers have turned to media due to manufacturer’s lack of response , , thus publishing

text: vulnerabilities for which no fix is planned;

text:  Some manufacturers do not perform frequent software updates, thus exposing automotive devices to known vulnerabilities (for instance in software frameworks, such as a SSL library or browser library). Such updates, even if released in due time by manufacturers, are still seldom deployed Over The Air and may require the car owner to use a USB stick for installing the update or to go a car dealership garage;  As confirmed by interviews, security functions such as security logs are not regarded as important, while they are essential to security diagnostics in the field.

text: 4.1.2 Liability

text: Studies show that most users are concerned with cybersecurity issues arising from the integration of connected features in cars. In case a security event happens, they are also likely to blame in equal parts the different actors of the ecosystem such as app stores, app developers and app manufacturers, to take the example of a vulnerability arising from a connected smartphone . Furthermore, there is no chance to enforce a perfect isolation between driving, debug and infotainment (or connected) systems, which means that vulnerabilities from any actor, including aftermarket components, may allow compromising safetyrelated features of a vehicle. In this context, there is a need to clarify the liability of each actor in case of a security event.

text: 4.1.3 Safety and security process integration

text: Development processes in place in the car industry take safety issues into account. Despite initiatives to

text: include security in these processes, there is still a lack of a common standard allowing a complete integration of safety and security in the car development lifecycles.

text: The lack of shared technical standards for car security is an additional burden for those who try to build

text: secure development processes. Eventually, the complexities of this heavily-tiered ecosystem cause issues in the supply chain and in the glue code between components.

text: Existing initiatives and limitations

text: The approach in SAE-J 3061 tried to address one of the smart cars specifics, which is a security product that has strong safety requirements and an existing engineering process dedicated to safety.

text: It also tried to distinguish between system level and vehicle level issues to define a development method for vehicles, which would both take security into account, and be compatible with the existing lifecycles of the industry. As such, the document is well adapted to smart cars, but still lacks recommendations to address many specifics of this domain. For example, the SAE-J 3061 does not suggest specific remediation to:

text:  The unusually large attack surface (large number of entry points and variety of attack methods) of smart vehicles ;  The combination of easy access for attackers (being a mass-market product) and severe impact (safety consequences on the user and other vehicles) ;  The persistence of threats, associated with the relatively long life of the products ;  The fact that smart features are not essential to the core features of the car .

text: Several initiatives led to defining guidelines or rules to implement security in the automotive industry (see 117,118 figure hereafter), and other initiatives asked for collaboration on the security topics from the automotive industry. Although some of them are well under development, like ISO/AWI 21434 , none of them can be considered a standard yet, and the overall standard landscape has yet to achieve the level of completeness and consistency found in domains such as aircraft safety or smartcard security. The Figure 9

text: hereafter gives a sample of existing initiatives, as well as a sample of initiatives of interest outside of the automotive domain.

text: At the moment, no certification framework is yet considered a standard for security evaluation or security testing, which would allow detection of vulnerabilities before the product is released. While certification frameworks exist for safety features, for example automatic brake system, most industry actors are still new to the concepts and methods of security certification (for example, the notion of penetration testing).

text: Other industries (for example airborne systems) eventually defined their own frameworks, for example when facing heavily-tiered environment rendering usual certification standards impractical. Before trying the same approach on automotive products, one should be careful to assess whether these attempts have been successful in practice.

text: The particular issue of technical standards

text: The lack of standard ultimately causes additional security issues: for example, several key components of vehicles are still developed with proprietary technologies (the main example coming to mind is the protocols used for CAN communication). This situation makes it more difficult for third-party vendors to develop security solutions (for example firewalls or intrusion detection) that could be applied to a large market, hence reducing effectively the cost of security for manufacturers.

text: Additional issues: supply chain and effects of re-used code

text: Moreover, the heavily-tiered ecosystem of car manufacturing also leads to security integration issues . Eventually, aftermarket products may share the same buses, which also lead to a significant risk . Units

text: such as TCUs can be provided by manufacturers, Tiers or aftermarket providers. Theoretically, all are equally secure or vulnerable, but the ECUs from Tiers or aftermarket providers are more significant from a remediation point of view.

text: As stated by researchers , security issues in aftermarket products cannot, by definition, be controlled by manufacturers. In practice, aftermarket vendors are described as fully supportive, but the complexity of the supply chain relationships leads in practice to security patches not being deployed, even when vendors have distributed them (similar issues can be found in smartphones, where security patches on the Android OS are not necessarily cascaded in operators or vendors fine-tuned versions of the OS).

text: Other studies highlighted the issues caused by integration of SW and HW in the manufacturing, especially the fact that some actors experience with safety issues may cause them to separate software and hardware issues and miss global security vulnerabilities. More generally, the outsourcing model leads to glue code and security flaws due to bad understanding of the security assumptions of third-party code . While acknowledging the effort made by the industry to integrate safety and security approaches, explicit synchronization points should be defined between these activities and between actors of the supply chain.

text: In the field, this heavily-tiered environment causes additional issues. Security patches need to be validated on the whole supply chain before they can be deployed, which leads in practice to security patches not being deployed, even when the Tier-2 vendor, for example, has developed and distributed them (this issue is, in a way, similar to the issues of a mobile OS security patch not redeployed by OEMs).

text: Constraints and incentives 4.2.1 Constraints Constraints due to the use cases

text: Some studies point out that connected car use cases, themselves, could be inherently insecure. For example, the use of some "smart dongles" is often described as a "bad practice" by construction: structural vulnerabilities of the CAN bus have a very deep impact (MiTM, capacity to reflash ECUs, leading to possible actions on brakes, throttle...). The user is only protected by the need for a physical access to the CAN (typically via OBD-II). In this context, those "smart dongles” provide an attacker with the capacity of easily performing a remote attack with the same high impact , which means that there must be a better protection offered for and a separation between dongles and the CAN bus.

text: Additionally, use cases lead the acceptable cost for some car components. For example, keyless entry systems have an acceptable cost, which implies that they will eventually lack the hardware resources to support state-of-the-art cryptography.

text: Constraints due to the architecture

text: Additionally, vehicle systems have very specific issues due to their architecture. In particular, the use of CAN bus (as opposed to Internet-like protocols) would cause:

text:  Greater vulnerability to DoS, since arbitration is priority-based ;  More issues with network segregation (priority being implicitly derived from safety notions instead of including security properties);  Greater vulnerability to reverse engineering due to the small range of valid CAN packets (meaning that 126,127 little work is needed and a simple fuzzing campaign can have a dramatic impact by itself) .

text: Moreover, in-vehicle systems include a very large number of embedded and interconnected components (a typical car contains more than 100 ECUs). Previous studies tend to argue that usual hardening and network isolation issues are insufficient to protect such interconnected systems .

text: It also opens many entry points for an attacker: vulnerabilities in these ECUs may be accessed remotely 130 131 through multiple possible interfaces, and in some cases including a web browser .

text: Aside of the remote interfaces, various local entry points and diagnostic/test interfaces exist, such as OBD or USB ports, which can also be used to get access to the system, or at least understand how it is designed and which messages are exchanged. Indeed, the legacy bus system (CAN, LIN) offers no protection of the messages. Besides, there is no standard for protection of ECUs (authentication, firmware update), which is left at manufacturers good will. Eventually, many entry points are physically accessible:

text:  Proprietary connectors : a proprietary implementation does not prevent the tester to find out that it is an Ethernet interface, and to be able to communicate with it,  Reverse engineering of the firmware (in this example, it allows to learn the password rotation scheme and the location of the new password in plaintext on the file system).

text: 4.2.2 Incentives

text: Studies consider that the IoT integration into cars cause a leadership crisis amongst traditional manufacturers, that are now challenged by actors coming from the software domain . Companies from different domains have different ways to deal with security issues, from disclosure to remediation, which in turn has consequences on the amount of “brand damage” resulting from inevitable cybersecurity issues. In this context, the deployment or non-deployment of cybersecurity measures may have far-reaching consequences.

text: Other studies point to the general perception, by many industry actors, that there is no direct return-oninvestment for security , which can be attributed to the difficulty to assess the financial impact of hypothetical security flaws.

text: This tends to confirm a widely-accepted consensus that media attention, and more largely, good or bad publicity , due to security issues is a main driver to implementing security for industry actors. This consensus was confirmed by the interviews performed during this study, whose results are highlighted in Public authorities can also drive change, as shown by the recent set of incentives by the US Department of Transportation with their Federal Automated Vehicles Policy, or the US National Institute of Standards and Technology’s Cybersecurity Framework.

text: Table 7 (the most critical ones are highlighted in bold).

text: Public authorities can also drive change, as shown by the recent set of incentives by the US Department of Transportation with their Federal Automated Vehicles Policy , or the US National Institute of Standards and Technology’s Cybersecurity Framework .

text: Good practices

text: The Figure 10 hereafter summarizes the good practices identified in this report. The good practices are described in the remainder of this document, and further explained in Appendix B. They are categorized as

text:  Policy and standards  Organizational measures  Technical

text: 4.3.1 Policy and standards 4.3.2 Organizational measures 4.3.3 Technical

text: This section is structured following the lifecycle of smart cars. Steps are inspired by previous work from NHTSA/NIST

text: 5. Recommendations

text: Our recommendations aim at enhancing trust within the actors of the ecosystem (car manufacturers, tiers and aftermarket vendors), as well as the trust from citizens in the smart cars available on the market.

text: Improve cyber security in smart cars

text: Recommendation intended for: smart car manufacturers, tiers and aftermarket vendors

text: The first recommendation of this report is the most obvious one: industry actors must establish holistic secure development processes for their products. It must include design, development, testing, and security maintenance in the field. This report gives a possible starting point for the establishment of good practices and we expect that industry actors will adopt these practices and effectively enhance the security of their products.

text: By providing a first set of good practices in this report, we hope that the industry should be able to overcome the challenge of Insecure design or development identified in section 4.1.1.

text: Improve information sharing amongst industry actors

text: Information sharing is essential for several reasons. Sharing can help industry actors to:  build trust between stakeholders ( car manufacturer, Tiers etc),  contribute to (make and) accept standards,  improve integration through commonly accepted practices,  help industry actors to find countermeasures and challenge the relevance of their security mechanisms,  provide a mechanism to challenge and develop the skill of security teams, and  support the detection and mediation of security issues.

text: Therefore, stakeholders should share and discuss new attack methods found in the wild, in order to help the whole community find countermeasures. Therefore, information sharing will also contribute to overcome the challenge of Insecure design or development identified in section 4.1.1.

text: Eventually, information sharing structures are an efficient way to challenge the skills of security teams by common sessions with other industry players, laboratories, or national agencies.

text: Clarify liability among industry actors

text: Recommendation intended for: smart car manufacturers, tiers, aftermarket vendors, insurance companies

text: This report identified a particular challenge related to liability (see section 4.1.2). The question of liability needs to be addressed. The question of where liability may fall lies between Tier actors, car manufacturers, the vendors, aftermarket support operators and the end users. The liability issues have to be addressed in the context of national legislation and case law. Where gaps are identified in national legislation, these should be addressed.

text: Criteria and processes

text: There are many ways to define criteria and processes to pinpoint liability in cases of security issues. We give hereafter an example of such a process:

text:  The HW vendor could be rendered “liable” by a certification of the hardware. The HW vendor could be considered liable for any issues occurring in the HW, provided the OS or runtime environment complies with the HW security guidance;  The vendor of the OS or runtime environment could be rendered “liable” by a certification of a composite product (consisting of the runtime environment and a given security hardware). The vendor could then be considered liable for any issues occurring in the OS or runtime environment, provided the applications comply with a specific set of rules . The notable point here is that the rules are meant to allow an automated verification, typically by code analysis. Such analysis could, for example, be performed when an application is submitted to an app store.

text: This example typically follows the practice of composite evaluations under the Common Criteria scheme and is applied today in the smartcard environments. While car manufacturers are not expected to directly use a scheme like Common Criteria, a similar approach would contribute to ensure:

text:  That a given HW is a secure basis for an ECU  That a given OS is secure when used on a given HW  That clearly defined, and easily verifiable rules have been defined for applications, so that they do not threaten then security of the OS

text: While it is generally accepted that evidences need to be given for the previously points, the processes that should be followed may differ.

text: A first step for the security of these systems is to build robust and clear security specifications that will be followed all over the lifecycle of the development and deployment of a car. Evidences that a system follows these specifications should be systematically be provided.

text: A confirmation of the fulfilment of these requirements could be done by performing security evaluations and/or certifications (under a well-adapted certification scheme).

text: Actors of the automobile industry are challenged by legal product liability regulation (comprising the “smart” devices), which includes also systems or services contributed by subcontractors. Because of this reason, early contact of the car manufacturer with its subcontractors on one side and the dedicated (product) liability insurer on the other is recommended. Contractual agreements can be used in order to preserve each actor’s rights.

text: Achieve consensus on technical standards for good practices

text: Recommendation intended for: industry groups and associations

text: This reports lists good practices (see section 4.1), which are not meant to be directly applied on a car design. Instead, they are meant as an input for a standardization effort. Industry actors should be aware that a security standard for smart cars should challenge all the categories described in these good practices, in order to be relevant security-wise. The details of the security requirements, on the other hand, must be carefully built with regard to actual products, and this report recommends that these requirements are subject of transparency and sharing between the different actors.

text: Following discussions with different participants in this survey, it is not recommended to create a new global standard applied to any present and future automotive, but different actors should use and combine the existed standards in order to better fit them in their use cases. The created consensus should be the golden mean between standards, regulation and in-house solution.

text: Define an independent third-party evaluation scheme

text: As security awareness increases among car manufacturers, they now include security in the life-cycle of their product:

text:  Requirements for their products for the design phase,  Security validation once the product is ready, to check conformity to these requirements and robustness of security functions,  Security maintenance of the product through updates. However, the automotive industry mostly assesses security with the same methods as safety (following methods similar to ISO 26262 or MISRA). These standards marginally address security, and help reducing malfunctions and failures (random and systematic faults), but do not protect against attacks.

text: This issue is part of challenge of Safety and security process integration described in section 4.1.3. In order to overcome this challenge, the industry should define security validation processes that explicitly address abuse cases and attacks, which requires a simulation of such attacks (in other words, penetration testing).

text: This requires different skills, and a different mindset as validation testing based on compliance to specifications. For this reason, we recommend to build upon the existing skills and evaluations schemes already in use amongst security professionals.

text: An example of such a scheme can be found in the initiative led by the Car-to-car communication consortium, which aims at defining a Common Criteria Protection Profile (PP), at the EAL 4 level, for vehicle communication devices . The PP may not address all the categories of good practices of this report. However, the integration of the Common Criteria scheme ensures the security assessment by skilled thirdparty laboratories, supervised by national cybersecurity agencies, following a standard process.

text: We suggest that the industry builds on these examples to clarify a shared standard for security validation. There is a need to define which method should be used (from basic security checks to penetration testing), the expected amount and depth of testing depending of the component to be tested, and the trust model for these tests (for example, certification of a third-party auditor with the authority to grant certificates based on security evaluation).

text: Build tools for security analysis

text: Recommendation intended for: industry groups and associations, security companies

text: Additionally to previous recommendations, industry actors may find other ways to improve their security testing skills. In particular, the development of dedicated tools appears as relevant for several activities. Many established tools from the software can be readily re-used without significant modification.

text: This report provides a first effort in the definition of tools for:

text:  Asset identification:  See Section 2.2 providing a first categorization of assets,  Threat modelling:  See Section 3 providing a first categorization of threats,  See Appendix A providing example of scenarios and risk ratings formulas according to the TVRA method. Industry actors should challenge these tools and further contribute on topics where tools provide the most value:

text:  Secure implementation, supported by static analysis during development, with rulesets adjusted to the automotive environment;  Security testing, for example by defining fuzzing tools;  Security monitoring, for example by defining intrusion detection on technologies such as CAN.

text: Improve exchanges with security researchers and third parties

text: Establishing communication channels between researchers, academics and the industry has benefited a number of sectors.

text: In order to improve this communication, workshops, conferences, working groups, etc. should be organised. Tools like responsible disclosure guidelines and bug bounty programs should be considered to be of special value to enhance the information exchange.

text: This kind of exchanges will be obviously quite beneficial for the sector, as security requirements can be taken into account from the early stages of the system lifecycle all the way to implementation and deployment.

text: 6. Glossary and abbreviations 7. Appendix A: Detailed risk ratings for the attack scenarios

text: These scenarios have various levels of likelihood and impact on sensitive assets. To illustrate this, hereafter is an example of risk rating. The rating uses the risk assessment method defined in TVRA, but: - This should not be considered a substitution for a real risk assessment on a car system - We apply this method to attack scenarios instead of vulnerabilities (in the TVRA sense) For these reasons, this rating should only be seen as a way to show how threats need to be assessed, in order for manufacturers to define priorities on the security issues that they might try to prevent. The Table 8 hereafter summarizes the ratings for the scenarios selected in this report, while Table 9 gives a rationale to explain the ratings.

text: 8. Appendix B: Detailed good practices

text: 8.1.1 Policy and standards

text: Table 10 summarizes the good practices selected during the interviews.

text: When consulting experts, a few policy enforcement topics were discussed:

text:  Industry actors should, as a first step, adhere to regulation related to security and privacy. Well aware of the regulation, several experts highlighted the lack of proper cybersecurity regulation for their field;  Car manufacturers should be held liable for damages due to other actors under their control, notably Tiers and garages;  Enforcing liability for damages due to aftermarket products was less a consensus amongst interviewees. The measure is practically difficult, thus is addressed in this report under the Gaps and Challenges section (4.1);  Eventually, liability can only be measured by the compliance to a shared standard and process, which is also lacking today (see 4.1)

text: 8.1.2 Organizational measures

text: Table 11 hereafter summarizes the good practices selected during the interviews.

text: Designate a dedicated security team. As dealing with cybersecurity issues requires a very narrow set of

text: skills, actors of the smart car industry should rely on specialists for several kinds of activities, notably risk management, secure design, training and awareness, penetration testing and corporate security. Whether

text: this security team should be in-house or a third-party company is not indifferent in some cases; in particular, risk management and corporate security require too much company knowledge to be easily outsourced.

text: Define a dedicated Information Security Management System (ISMS). Vehicles in the wild cannot be

text: completely protected if the company itself is not able to protect some particularly sensitive assets. For example, if vehicles or components have keys injected during production, the risk of leaking these keys may be more important on the company site than on vehicles themselves. For this reason, an effective ISMS may be of some help. The SAE J3061 describes such an ISMS , and references to standards often used to this purpose (ISO 27001 and NIST 800-53).

text: 8.1.2.1 Secure Development or outsourcing

text: Assess the threat model and use cases. This report gives examples of attack scenarios, along with a risk

text: rating, inspired by the TVRA method, for each scenario. Similar (albeit more detailed) risk assessment is to be expected from any actor involved in smart car components development. The threat analysis itself can follow several possible methods, none of them being a standard. SAE-J3061 describes a TARA (Test And Risk Assessment) phase, which fully supports the EVITA, TVRA, OCTAVE and HEAVENS approaches.

text: Provide security by design. The security should be taken into account no later than the design phase, in

text: order to avoid unnecessary workarounds, refactoring costs, or worse: leaving vulnerabilities unaddressed because a fix would be unpractical or too expensive. In particular, the secure design should demonstrate how the vehicle security covers the threats identified in the risk assessment. Design should also take into account cybersecurity key principles such as defence in depth or principle of least privilege , or the use of a hardware-supported Trusted Computing Base (TCB) small, secure and trusted, for critical services.

text: Implement and test the security functions. The test phase should also assess how hard it is to bypass the

text: existing security functions, activity which is typically performed by penetration testing. Examples of security controls and measures are described in the next section. These technical measures are sorted using categories loosely adapted from the Common Criteria security certification standard. These categories are:

text:  Security Audit: security events must be logged, and users should be notified whenever needed;  Communication protection: communication should be protected against disclosure, modification, replay and denial of service;  Cryptography: Confidentiality, integrity and authenticity must be protected by using strong and standard cryptography. Keys must be managed securely, and the use of a trust infrastructure (such as PKI) is encouraged;  User data protection: the integrity, confidentiality and authenticity of user data must be protected. Confidentiality protection must be defined with regards to privacy issues;  Identification, authentication, authorization: strong authentication methods must be used, as well as access control mechanisms. Passwords and sessions should be managed accordingly;  Self-protection: HW and SW self-protection measures should be in place to protect previous security functions. Data used to enforce these security functions should be protected, and hardening should be used to reduce the attack surface.

text: 8.1.2.2 Security measures until the end-of-life

text: Following the good practices described so far shall significantly reduce the risk of having vulnerabilities found in the product, however this risk can never be avoided. Vendors shall not only pro-actively perform a survey for new vulnerability but also provide a secure and reliable device update mechanism to allow fixing vulnerabilities.

text: Assess the security controls and patch vulnerabilities using appropriate assessment procedures. Determine

text: the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.

text: Define a security update policy. The notion of security update has to be applied to smart cars with several

text: specifics in mind:

text: - The timing and conditions of the update are different in a vehicle than on a personal computer (users should not be forced to wait for an update before they can start driving. On a similar note, it would be unacceptable to disrupt operations when the vehicle is driving); - A connected vehicle includes several types of components with different update policies: apps, secure elements and ECUs cannot be updated the same way. While a secure OTA update seems theoretically possible for all components, the need for physical updates might still be present in the next years in many cases; - Standard are still missing for these operations. While several OTA update framework already exist in several domains, the car community still has to commit on a given, secure process if they want the same channels to be used for manufacturers, Tier-1, Tier-2 and aftermarket developers. Some specific aspects, such as certificate formats, might also need standardization to be fully adaptable to the connectivity constraints of connected vehicles.

text: Some recommendations apply to the update policy:

text:  The end-user must be informed of the support period of the device and of the end of support for security fixes.  A patch may consist of a workaround if the developer did not yet provide a fix.  When over-the-air updates are not available, a plan for product recalls shall be considered.  For online services supporting smart cars, a rollback to a secure state must be possible.

text: Other aspects of the update cannot be addressed directly by this study. For example, applying security updates must be done only when it cannot cause a safety issue, which requires each manufacturer to define appropriate policies. In the same manner, manufacturers may have to think whether a vulnerable component can, or should, be put offline when found vulnerable.

text: Perform vulnerability survey. Once a device is on the market, the vendor must perform a vulnerability

text: survey and fix security flaws accordingly. The vulnerability survey should include developer findings, on-line researches, CERTs advisories, as well as input from customers and security researches. Eventually, vulnerabilities impacting user data should be communicated as transparently as possible. The EU Opinion 03/2014 on Personal Data Breach Notification from the

text: Article 29

text: Working Party gives examples of such

text: situations . Manufacturers already move towards using dedicated Security Operations Centers to monitor their infrastructures . While a SOC generally do not delve into in-vehicle vulnerabilities, it may:

text:  Detect anomalies that are an indication of a vehicle compromise  Prevent compromising critical functions of the infrastructure, such as remote provisioning or OTA updates

text: Building a strong security community on a given domain gives many benefits:

text:  Information sharing groups such as CarSec in Europe, or ISACs, can contribute to raise awareness amongst industry actors;  CERTs prove useful in informing users of possible vulnerabilities and remediation. While existing CERTs can occasionally play this role for automotive use cases , dedicated incident response capabilities might prove more efficient.  Having a transparent dialog with security researchers, may provide manufacturers with a quicker assessment of their products’ possible flaws. It may also “push” the whole community towards more responsible disclosure practices,  Setting up bounty programs, as already done by several car manufacturers, can also help finding flaws before they are exploited by malicious actors.

text: A few more recommendations apply:

text:  A policy for vulnerability handling and disclosure awareness should be defined . 161 162  Bug bounty programs can also provide an incentive to third-party researchers .  Known vulnerabilities must be patched .

text: Check the security assumptions regularly during life-time. The devices and services made assumptions to

text: ensure that the security requirements are sufficient. Vendors and users should be encouraged to check regularly that these assumptions are still valid. For example: limitations in the usage of the vehicle , 165 166 assumed properties of the environment , assumed properties of cryptographic properties …

text: Protect the software update mechanism. In all cases, the update process requires the vehicle to

text: authenticate the party providing the update, as well as the carrier of this update (for example SMS authentication does not replace the firmware signature, but is used as a complementary countermeasure)

text: Security updates provide protection against vulnerabilities found during the life of a device or application . However this comes at a cost, since support of this functionality also provides an entry point for an attacker.

text: In particular vendors should:

text: o Provide automatic and timely security updates ; o Protect the updates (typically via encryption and digital signature). The update files must not contain sensitive data . The signature must be verified before the update is applied; o Protect the application of an update on the device. An attacker should not be able to trigger a firmware installation without an authorization; o Protect the security update interface against attacks; o Maintain the update server, to avoid attackers using an obsolete domain name to push malicious updates .

text: Raise users’ awareness. Vendors should explain users what actions can contribute to mitigate potential

text: threats, especially how to securely use interfaced systems such as a smartphone.

text: 8.1.3 Security functions

text: 8.1.3.1 Security Audit

text: Security events must be logged , and access to the logs must be documented and protected from disclosure to unauthorized users. Logs are also needed for device integration. Typically, Tier-2 suppliers

text: must give possibility for Tier-1 suppliers to understand security events happening in their products. However logs may also give information to an attacker, which is a serious security drawback. For this reason, the audit trail must be protected

text: Notifications should be easy to understand and help users find a remediation or workaround. HW and

text: embedded systems should provide clear error data that can be leveraged upon by the SW vendors. The user

text: must be notified in case of security errors, updates or compromised data in a device or service they use. In particular, users must be notified in the case of security events . Notification might vary greatly depending on the type of software considered. Mobile applications notification, messaging such as SMS or e-mail, hardware interfaces such as LEDs, dedicated error messages to a gateway …

text: 8.1.3.2 Communication protection

text: Provide end-to-end protection in confidentiality and integrity using protocols that resist to replay attacks.

text: Favor methods providing forward secrecy whenever possible. This should be true even for the communication of already encrypted data ; encryption must cover not only WAN traffic (internet, mobile network), but also local network .

text: Mitigate vulnerabilities or limitations of standard security library. Using a standard security library does

text: not mean that the product will automatically be secure. Developers must be aware of the vulnerabilities (due to a flawed implementation) and limitations (vulnerability of the protocol itself) of the third-party components they use. They should mitigate them whenever possible by performing patching and by

text: securing the configuration of the communication stacks , which might typically include Bluetooth ,Wi-

text: Fi , TLS …

text: Consider denial of service as a usual threat to communication infrastructures . This threat should be addressed from the design phase of the infrastructures. On this topic, this study encourages the vendors and

text: service providers to read the ENISA Internet Infrastructure Threat Landscape (for network components) or the GSMA IoT Device Connection Efficiency Guidelines .

text: Protect remote monitoring interfaces. SMS commands should not be protected only by whitelisting . For this reason, privileged commands such as SMS administration commands shall be protected by mutual authentication. More generally, protection of remote monitoring interfaces is crucial since they often provide a highly-privileged entry point into a device. This protection includes access control for both the gateway and ECU level and authentication mechanisms.

text: 8.1.3.3 Cryptography

text: Many protection measures rely on cryptographic functions. In a broad definition, cryptography support for security must include:

text:  Symmetric or asymmetric encryption;  Message authentication and integrity;  User/entity authentication;  Hash functions;  Digital signature;  Key management;  Random number generation.

text: Do not create proprietary cryptographic schemes, but use state-of-the-art standards instead. Even a home-brewed implementation of a standard is not a good practice when standard implementations are available. If needed, consider getting advice from security experts or your national cybersecurity agency. If no recommendations exist for vendors at a national level, ENISA recommendations should be considered as a reference. This applies also to random number generation, which is a critical part of the cryptographic support. A possible recommendation would be the use of cryptographically secure pseudorandom number generators.

text: Rely on an expert in cryptography for interfacing with HW accelerated cryptography or secure elements, or even using or configuring a standard implementation. These tasks are difficult for most of developers. If

text: not properly done, the security might be heavily reduced or even completely suppressed. This part should be performed by an expert in cryptography or at least a third-party code review should be performed to ensure that HW or a standard implementation of cryptography is properly used.

text: Consider using dedicated hardware security modules. HW-based cryptography solutions may help avoiding

text: the incorrect implementation of cryptographic algorithms by software vendors, as well the coexistence of multiple implementations of the same algorithms. They eventually provide implementations that are more resource-efficient. Choosing HW accelerated cryptography means that a reasonable assurance must be obtained on the quality of the HW implementation, since “bad cryptography” on HW will be leveraged on all the SW using these functions .

text: Eventually, using certified HW may solve most of these issues. In particular, Manufacturers may look for independently audited HW. The standard for independent assessment of security HW would be in that case either FIPS 140-2 or Common Criteria certification following relevant Protection Profiles. If needed, consider getting advice from security experts or your national cybersecurity agency.

text: Cryptographic keys should be securely generated, distributed (or provisioned), used, stored, and deleted (including revocation). Badly implemented key management can introduce vulnerabilities that may easily

text: be exploited. Devices without direct user interfaces are particularly vulnerable to PKI compromising. While users of a PC can easily delete or install certificates, such devices rely mostly on remote administration, and sometimes do not even allow end-users to perform such administration tasks. For this reason, Manufacturers, as well as Tier-1/Tier-2 and aftermarket vendors should consider very carefully the revocation mechanisms associated with their components. This is especially true when the mechanisms of key provisioning and management are performed over-the-air . If needed, consider getting advice from security experts or your national cybersecurity agency .

text: 8.1.3.4 User data protection

text: Identify personal data. The interpretation of privacy protection raises many issues, one of them being to

text: successfully identify what can be considered a personal data. The definition according to the EU Directive

text: includes data relating to an identified or identifiable person. In the case of smart cars, however, it may be safe to assume that most data related to the user activity are somewhat personal, especially location-based data. This last approach will have to be continued throughout the whole product or service

text: lifecycle. Metadata should be considered as personal data by default, since they are subject to the same threats . Consider getting advice from your national data protection agency.

text: Implement transparency measures. The interactions with the user (which should not be limited to the Terms

text: and conditions ) enable to cover the legal transparency requirements .

text: Design the product/service with legitimate purpose and proportionality in mind. The design phase of the

text: service or product, where the details of the processing have to be assessed with regards to the explicit and legitimate purposes. The actors must ensure that themselves and their subcontractors or suppliers do not process user data more than needed, and do not pursue an illegitimate purpose with regard to user data. As a general rule, third party components integrated in the device or third party cloud services should not access unencrypted user data unless user agreement has been obtained. Access control or anonymity/pseudonymity measures gives assurance that user data is not accessed by these third parties.

text: Define access control, anonymity and unlinkability measures to enforce the protection of private data.

text: These measures are typically access control measures , pseudonymity and unlinkability measures (such as ensuring that data is not correlated ), and eventually anonymity measures. Anonymity measures may be

text: Define measures to ensure secure deletion of user data in case of a change of ownership. More generally,

text: a secure factory-reset of the firmware and configuration should be available on the vehicle.

text: 8.1.3.5 Identification, authentication, authorization

text: Use mutual authentication for remote communication. Devices or users connecting to a server must be

text: able to authenticate the server. Reciprocally, servers must be able to authenticate clients and users. Mutual authentication consists in demonstrating cryptographically to both the client and the server that they are communicating with the expected party. Mutual authentication is generally performed by using Public Key Infrastructures (PKI) and certificates. These methods can be embedded in protocols such as TLS. However using methods such as TLS does not grant a secure mutual authentication, unless:

text: • There is a certificate for both the server and the client; • Certificate are properly validated (ruling out, for example, the use of self-signed certificates); • Revocation lists are verified (alternatively, interrogations to an OCSP server); • All services require this authentication step . Which also means that even private URLs accessible on a device must require authentication; • Certificate pinning is used .

text: As a side note, it must be noted that certificate pinning does not eliminate the need for certificate validation. For example, the pinned certificate can be an intermediate or root Certificate Authority (CA) – which means that the end certificate still has to be verified against the CAs.

text: Use multi-factor authentication for user authentication. Users should be authenticated by 2-factor authentication whenever possible, including for authentication to cloud services or mobile interfaces , as well as local administration sessions of devices. Several methods can be used for multi-factor authentication. As an example, the NIST provides a summary of these methods .

text: Implement access control measures to separate the privileges of different users as well as the privileges of different applications. In practice, privileged operations should not be readily accessible to normal users. Reducing access to these services can be achieved either by disabling them (some studies recommend

text: disabling WAN administration, for example, since it provides a remote entry point to privileged services ; local administration such as JTAG could also be deactivated by using fuses) or by introducing dedicated access controls. Typically:

text: o An administrative access should always require authentication, and should ideally require unique credentials for each device208; o Not all individual accounts need to have access user data stored in the device or associated services ; o User accounts must be unique and separated for both local and distant services ; o The device must distinguish between normal users and admin users. The latter only have access to configuration functions .

text: Implementing privilege levels, rings or domains can also be extended to application separation. Some platforms implement such levels in hardware. If such functions are available, vendors are advised to use them . If not, operating systems already provide capacities to implement privilege control. At the firmware / software level, access control must be used to control access rights of both applications and individuals. In particular, not all applications need to be root or be executed in kernel land.

text: Allow and encourage the use of strong passwords. As it is regularly demonstrated, passwords are often a

text: weak point, whether they are weak user passwords or weak default passwords for products internal services. Many devices use strong protection measures that are defeated by the lack of proper password management . This concerns all possible uses of passwords: direct device interfaces such as JTAG, but also web, mobile or cloud interfaces. The usual measures are the following:

text: o Allow and encourage the use of strong passwords , regardless of the presence of a second authentication factor; o Require the user to change credentials (username, password) at their first login ; o Do not use hard-coded or “default” passwords or shared passwords, for instance for remote support accounts; o Do not store/expose passwords in clear text or with weak protection. Adaptative one-way functions such as PBKDF2, scrypt or bcrypt should be preferred ;

text: o Use countermeasures against password guessing / account harvesting . Services must be protected against: o horizontal guessing (testing a small number of usual passwords on a high number of user accounts); o vertical guessing (testing a high number of passwords on a single user account) o This typically includes lock-out and delaying measures as well as high password strength / entropy and diversification of passwords across devices. This also includes countermeasures against account discovery or other means used to exploit password recovery functions ; o Define options for password control. Typically, in the case of an administrator account, the default 219.220. option should require strong passwords by default

text: Password policies are eventually useless if the final user is not fully aware of the threats and good practices. Vendors and service providers should consider raising the awareness of their users whenever possible, for example to support the use of password managers. Examples of simple guidelines can be found in ENISA Basic security practices regarding passwords and online identities .

text: Since the use of strong passwords is not acceptable for normal users interactions in a moving vehicle, this good practice is recommended mainly for setup and pairing activities, and especially for administration or diagnostic features.

text: Enforce session management policies to avoid session hijacking. Session management also contributes to

text: making sure that the authorized user is the one using a given session. Typically:

text: • Sensitive functions such as administration via web services should require reauthentication. • No data should be transmitted before authorization. • Strong (random) session handlers should be used to avoid replay. • The user must know at any time if, and why, they are logged on a particular service, meaning that no passive sign-up for third party services should be performed.

text: 8.1.3.6 Self-protection

text: Define a consistent policy for self-protection. Self-protection includes all measures taken to enhance the

text: robustness of previously mentioned security functions. Developers should challenge every security function

text: of their design, consider how they could be bypassed or weakened, and eventually implement selfprotection measures. The main topics considered here are:

text:  Hardware self-protection: these measures aim at protecting the hardware against physical attacks or observation. They include tamper evidence or tamper resistance, and secure design measures  Software self-protection: software also contributes to protect existing security functions, typically by validating inputs and outputs, or by separating the capacities of the different software components (levels of trust, virtualization…). Self-protection can also be addressed by validating the software state in-memory (in order not to execute commands that it wasn't intended to do originally) or running only signed binaries (in order to fight against dropping of malware). Software self-protection can also be achieved by using two separated OS; a secure one to perform security functions and a “normal” one (e.g. Linux, android) for any other use.  Non-user data protection: data used to enforce the security functions should be protected. These measures intend to avoid storing internal keys as cleartext, or any other data that could be used to circumvent the service security.  Hardening: hardening consists in reducing the attack surface of the product or device. This includes removing unused services or interfaces (for instance remote shell access to the device, which should not be needed in production), as well as integrating malware protection. Hardening in smart cars is particularly difficult to address, since these systems are behaving both like embedded and networked systems. Some actors have advocated that, in the CAN context, intrusion detection should be used on top of firewalls, in the same manner as usual IT systems use both in a defense-in-depth approach . Dedicated solutions are already being commercialized, in order to provide CAN bus monitoring in a fashion quite similar to the traditional IDS/IPS systems . This study will not, however, conclude on the respective merits of these solutions.

text:  Isolation: this subset of hardening measures is especially relevant for the car industry. Isolation of components aims at reducing the capacity, for an attacker, to jump from a component to another. This notion is found in the two main paradigms for CAN bus isolation in cars: o Solution 1 : the CAN bus related to driving systems is “air gapped”, that is, completely isolated from the infotainment network and internet o Solution 2 : Systems are connected, but a gateway is in place to ensure the isolation between networks, typically by access control mechanisms These two solutions have architectural consequences – for example, the first only allows physical updates, while the second allows OTA updates. Studies argue that the second solution is gaining momentum, especially now that the eCall regulation requires a SIM-card to be present in all cars, which provides a channel for updates . More generally, a separation of telematics and infotainment traffic is recommended allowing specialized handling of packets regarding intrusion and malware detection.  Updates: updates are a subject of other self-protection measures. However, it is a quite important function which is not always sufficiently protected. Updates may be used to update the vehicle’s system with new functionalities, but also to provide corrections of security issues for the system. Different parts can be of the need of an update, e.g. infotainment applications, maps, other

text: applications of the system or even the entire Operating System.

text: Nowadays, most of these updates are planned to be performed using OTA connectivity OTA updating should reduce the cost of updating vehicle software, while improving functionalities and fix issues (functional or security) on the car. However, as already mentioned before, a particular attention has to be done on the downloaded updates. Only signed updated should be finally installed whether an authentication could also be required.

text: Most of the self-protection measures must be considered from the early design phases. Only the hardening can be defined as an additional measure that can take place after the design and implementation phases.

text: Implement HW tamper evidence / tamper resistance. Devices vendors should be aware of tamper evident

text: or tamper-resistant mechanisms . While they are not recommended in any case, vendors should consider using them depending on the level of sensitivity of the assets stored on the device. In particular, even constrained devices could be able to implement some kind of tamper evidence, even if they are not able to implement resistance and response. More details on anti-tamper technologies can be found at different 233 234 sources, for example Black Hat or ICCC conferences

text: Implement HW protections at the design level. Hardware design can be used to make the device harder to

text: attack .

text: Protect the software security functions by reinforcing interfaces and strengthening the application separation at runtime. Software can contribute to self-protection measures for instance for robustness of

text: interfaces against bad inputs . Secure implementation, thoroughly tested, will protect against common attack vectors such as buffer/heap overflows or OWASP’s List of the Top Ten Web Vulnerabilities . This typically includes robustness of network interfaces against buffer overflows or fuzzing . Implement trust zones for the execution of applications (and/or ensuring segregation or execution protection), for example by whitelisting applications, or by using Trusted Execution Environments or Secure boot, or SW virtualization …

text: The default configuration of devices and services should be secured. The operation mode of the device (or

text: service) should be the most secure one by default. A user might arguably want to disable a given security function, but this should be the consequence of a deliberate action from the user, and the user should be warned that this change reduces the security of the solution .

text: Encrypted storage is not only useful to protect user data, but also to protect data that is needed to enforce

text: security on the device . Internal data may be just as sensitive as user data, but are often not protected

text: enough, leading for example, to situations where "hardcoded root credentials, API keys for Amazon Web Services, URLs never meant to be known to end-users, and manufacturing network configurations" can be found in cleartext on devices. As a general rule, configuration data should be encrypted at rest and in transit .

text: Perform hardening to reduce the attack surface: remove unused services or interfaces, integrate dedicated security software, activate memory or control flow protections. For devices that have a

text: complete operating system, several measures can be considered to harden the device, such as ASLR, nonexecutable memory, process segregation or sandboxing. Another measure is removing unused tools, services and libraries . Unnecessary services should not be present on the device (typically telnet must always be deactivated, but even SSH or FTP can be deactivated in many cases). This type of measures is also applicable at a network level: the device should not leave open ports, especially ports that could be exposed via plug-n-play protocols . The default configuration of the device should be based upon the most secure parameters, and users should be warned if they have the possibility to roll back to less secure parameters. For example multi-factor authentication should be the default configuration. Users should be warned if they want to configure the service to single-factor authentication. Vendors should also consider integrating malware protection to their systems , since the smart home ecosystem provides many possible ways for malware to enter a device (mobile, personal computer, device network interfaces…). Eventually, Vendors should consider deactivation or protection of the external interfaces , for example:

text: • protecting the physical debug interfaces such as JTAG/ISP (by password and physical action), or physically deactivate the physical debug access; • including mitigation to avoid exploitation of interfaces such as I2C/SPI buses or serial interfaces; • Suppressing or limiting to a local access , the administration interfaces.

text: More generally, vendors should consider their means of protection for:

text: • Boot ROM interface; • Firmware update interfaces; • Configuration and calibration interfaces; • Inter-processor IPC; • USB external interfaces; • Protection against DMA attacks ; • No unnecessary external interfaces should be accessible from the exterior of the device .

text: ENISA

text: Athens Office

text: 1 Vasilissis Sofias Marousi 151 24, Athens, Greece TP-07-16-043-EN-N

text: PO Box 1309, 710 01 Heraklion, Greece ISBN: 978-92-9204-184-7 doi: 10.2824/87614 Tel: +30 28 14 40 9710 info@enisa.europa.eu www.enisa.europa.eu