SECURITY ASPECTS OF WIRELESS AUTOMOTIVE APPLICATIONS

JANANISHRRI J., SANDHYA S., SATHVIKA A.

Department of Electrical and Electronics Engineering-III-year
Coimbatore Institute of technology

ABSTRACT

This paper considers security requirements for wireless automotive applications and
describes the processes used for identifying and prioritizing such requirements. The security
engineering process starts from use cases for automotive onboard networks that require wireless
communication interfaces and involves an investigation of security threat scenarios and the
assessment of the relative risks associated with the threats. We conclude that even though quite
some effort has already been expended in the area, most of it has been directed towards problem
definition and not so much towards security solutions. We also highlight a few areas that we
believe are of immediate concern.

INTRODUCTION

Future automotive safety applications based on vehicle-to-vehicle (V2V) and vehicle-to-

infrastructure (V2I) communication (jointly referred to as V2X communication) are regarded as
a means for decreasing the number of fatal traffic accidents. While these functionalities herald a
new era of traffic safety, new security requirements need to be considered in order to prevent
attacks on these systems. Modern cars are equipped with up to 70 embedded ECUs (electronic
control units) and electronic sensors and actuators for a diversity of functions. These components
are connected via various communication buses, forming a complex distributed system. So far,
there has been little incentive and opportunity for tampering with automotive on-board networks.
This will change with the advent of new wireless communication interfaces. The on-board
electronics will be threatened by attacks originating both outside and inside the vehicle, resulting
for instance in illegitimate message injection. Trust anchors and secure storage of secret keys and
secure, trustworthy communication within individual vehicles is the basis for the secure
deployment of electronic safety aids based on V2X communication. Therefore, security-relevant
components of automotive on-board networks need to be protected against tampering and
sensitive data need to be protected against compromise. A careful analysis of the security
requirements is important in order to devise security measures that are both effective and cost-
effective. This paper outlines the security requirements analysis process that we have applied to
automotive on-board networks with V2X communication interfaces.

IDENTIFIED SECURITY PROBLEMS:

Here follows a summary of the identified security problems:
• Lack of sufficient bus protection: The CAN-bus lacks necessary protection to ensure
confidentiality, integrity, availability, authenticity, and non-repudiation. Messages on the CAN-
bus can be read by other nodes, have no sender or receiver address, and are not protected by any
Message Authentication Code (MAC) or digital signature. Analysis of the CAN and Flex Ray
specifications also concludes that these protocols lack necessary protection of data
authentication, data confidentiality, and data freshness. However, there is some protection for
data integrity and data availability.
• Weak authentication: It is possible to illicitly reprogram ECUs with new firmware. The
reason for this is weak authentication and sometimes no authentication at all.
• Misuse of protocols: Attacks towards the in-vehicle network can be performed by
misusing well-chosen mechanisms in the protocols. Thus, for the LIN-bus, sending malicious
sleep frames could disable the subnet. For the CAN protocol, a Denial-of-Service (DoS) attack
may be carried out using the bus arbitration mechanism. By sending messages with the highest
priority, no one else will be able to use the bus. Furthermore, well-formed malicious error
messages could be used to attack the fault detection mechanism implemented in CAN and Flex
Ray, so that the controllers will disconnect from the network.
• Poor protocol implementation: In some cases the protocol implementation is such that it
does not properly reflect the protocol standard. For example, the standard specifies that it should
not be possible to put the Engine Control Module (ECM) into programming mode while the
vehicle is moving. Obviously, this is for safety reasons. However, in some implementations it is
indeed possible to launch a command that would disable the CAN communication and put the
ECU into programming mode despite the fact that the vehicle is moving.
• Information leakage: An information leakage from the vehicle can be triggered by
manipulating the diagnostic protocol, creating a potential privacy violation. The information
leakage was accomplished by sniffing an ordinary diagnostic session, and then replays a
modified version of the traffic. Since the gateway is unable differ ordinary traffic from
diagnostic traffic, both types of traffic will be forwarded by the gateway.

THE SIX TYPES OF HACKERS:

 Researchers and Hobbyists

 Pranksters and Activists
 Owners and operators
 Organized Crime
 Nation-states
 Transportation Infrastructure.

DESIGNING SECURE AUTOMOTIVE SYSTEMS

Now that we have reviewed some potential threats and vulnerabilities, the next issue is
designing secure automotive systems. While the automotive security field is relatively recent,
there are strong technologies and expertise in adjacent industries to be leveraged and adapted.
Developers can take advantage of existing secure development processes to incorporate security
and privacy into their new vehicles by design. There is a strong relationship between cyber
security for automotive safety. SAE has captured this very well in their J3061 Cyber security
Guidebook for Cyber-Physical Vehicle Systems. To paraphrase, system safety is concerned with
protecting against harm to life, property, or the environment. System cyber security aims to
prevent financial, operational, privacy, or safety losses. So all safety critical systems are security
critical, but there may be systems, such as entertainment systems, that are security critical but not
safety critical. The organizational disciplines that lead to safe and reliable cars also apply to
security. In particular, safety, reliability, security, and privacy must all start at the outset of the
design phase. To ensure a secure design, a threat model for the vehicle should anticipate different
kinds of threats and seeks to mitigate them. While the safety designer is adding in crumple zones,
airbags, proximity detection, and automatic braking systems, the security designer is also
building in layers of protection, seeking to isolate a threat before it can affect vehicle operations.
The vehicle security architect has a collection of security tools to choose from. Automotive
Security ranging from encryption of critical or private data to isolation of software components
by function can combine hardware and software functions as needed to meet cost and
performance goals. Perhaps the most important safeguard, which is different from commercial
computers, is the ability of systems to protect vehicle operations, as well as data and processes.
Software engineering approaches and cycles in the auto industry have typically been different
from corporate and PC processes, with longer time scales and little or no update or patching
capability. There is a substantial legacy of control systems and networks on a car, with each
system historically dedicated and independent. At one time, the complexity of automotive
systems might have been a barrier to entry for hackers, but that is no longer the case. Hackers are
more sophisticated and may be part of criminal or nation-state groups with significant skills and
funding. In addition, specifications for most chips and operating systems are readily available on
the Internet due to increased technology standardization and proliferation. As a result, as vehicle
systems consolidate and interconnect, security design has to be intentional and proactive.
Applying best known practices and lessons learned in the computer industry will be helpful as
vehicles become increasingly connected. Other industries and market segments, such as defense,
aerospace, and industrial machines, provide opportunities to adapt and cross-pollinate many of
the foundational principles, lessons learned, and processes developed over the past decades in
cyber security. For example, auto manufacturers could implement distributed security
architecture, exhibiting defense in-depth, analogous to the layers of protection analysis (LOPA)
methodology used for safety and risk reduction. Securing systems from the hardware to the
cloud, with identified best practices and technologies for each discrete building block, would
provide comprehensive, end-to-end protection. Realizing these protections in actual vehicle
systems requires coordinated design of multiple security technologies, such as isolation of safety
critical systems, secure boot, trusted execution environments, tamper protection, message and
device authentication, data encryption, data anonymization, behavioral monitoring, anomaly
detection, and shared threat intelligence. Distributed security architecture automotive computer
security is a collaborative approach of defenses to detect, protect, and correct identifiable or
avoidable threats and to protect from previously unknown or unavoidable ones. With next
generation cars, these layers include hardware-based protection in and around the ECUs,
software-based in vehicle defenses, network monitoring and enforcement inside and outside the
vehicle, cloud security services, and appropriate data privacy and anonymity for bumper to-cloud
protection. The key tenets of data privacy and anonymity must be safeguarded while ensuring the
security of the automobile. Users must also be educated about secure usage of the systems and
potential threats. For example, if they sync their phones to a rental or shared vehicle, which may
copy all of their contacts and location data, they must remember to disconnect and delete the data
when they return their cars. Security defense-in-depth consists of three layers: hardware security
modules, hardware services, and software security services. Hardware security protects the ECU
as a security enabler and enforcer. Its primary responsibilities are: secure boot to bring the
environment to the initial trusted state, secure storage of keys, and a trusted execution
environment. Hardware security services build on top of hardware security and provide fast
cryptographic performance, immutable device identification, message authentication, and
execution isolation. Software security services enhance security capabilities on top of the
hardware with network enforcement, whitelists/blacklists, anomaly detection, cryptographic
services, biometrics, secure over-the-air updates, and upgrade capabilities, all delivered over the
life of the car.

NETWORK SECURITY
With in-vehicle networks carrying a mix of operational and personally identifiable
information such as location, navigation history, and call history, microphone recordings
protecting messages and data over the communication bus is critical for operational security,
privacy, and consumer trust. Common protocols, such as controller area network (CAN), local
interconnect network (LIN), media-oriented systems transport (MOST), Flex Ray, automotive
Ethernet, Bluetooth, Wi-Fi, and mobile 5G and newly proposed protocols, like dedicated short-
range communications (DSRC)—amplify the threat, as they increase attack vectors. Replacing
unsecured legacy protocols with common protocols makes it possible to leverage good security
techniques that have been developed in the computer industry. Security-enhanced ECUs can
interact with security enhanced networking protocols (in-vehicle or external) to enhance
authenticity, reliability, and integrity of the transmitted data.
Hardware-assisted technologies that help to secure networks without significantly impeding
performance, latency, or real-time response include:

■ Message and device authentication: Verifies that communications are coming from an
approved source and protects authentications from being spoofed or recorded and replayed.
■ Enforcement of predictably holistic behavior of all systems: Restricts network
communications to predefined normal behavior and constrains abnormal types or volumes of
messages so that they do not impair the vehicle’s functions.

■ Access controls: Explicitly permit communications and messages only between pre-approved
systems and sensors, block unapproved and inappropriate messages, and alert security systems
about any invalid attempts. Manufacturers, maintenance organizations, owners, drivers, and even
police and insurance companies will have different access rights to the car’s information systems
that need to be authorized and controlled.

CLOUD SECURITY SERVICES

While embedded vehicle security is essential, some additional security services require
real-time intelligence and updates, so the systems need to be able to connect to cloud-based
security services in order to detect and correct threats before they get to the car.
These include: ■ Secure authenticated channel to the cloud: Leverages hardware-assisted
cryptography for remote monitoring, software updates, and other communications. Data
protection technology secures data throughout the transaction
■ Remote monitoring of vehicle activity: Includes appropriate privacy constraints
to help detect anomalous behavior and misbehaving vehicles and filter out and remove malware

■ Threat intelligence exchanges: Collaboration among dealers, manufacturers, and

government agencies to quickly propagate warnings and remediation of zero-day exploits and
new malware to the vehicle, containing the spread of an attack and retroactively identifying and
correcting previously infected ones.

■ Over-the-air updates: Used for firmware (FOTA) and software (SOTA) updates
and work well for smartphones and other consumer and business electronics. With appropriate
user controls and safety precautions, these are vital to get systems updated quickly when a breach
or vulnerability is discovered and substantially reduce the cost of recalls.

■ Credential management: The online component of vehicle, owner, and driver

authentication, providing easy and secure management of user profiles and account information,
federated identities, and associated cryptographic keys and services. Security of credentials is
critical to data privacy.

REFERENCES

[1] P. Kocher, R. Lee, G. McGraw, and A. Raghunathan, ―Security as a New Dimension in

Embedded System Design,‖ in Proc. of the 41st annual Design Automation Conference. New
York, NY, USA: ACM, 2004, pp. 753–760.
[2] R. Brooks, S. Sander, J. Deng, and J. Taiber, ―Automobile Security Concerns,‖ Vehicular
Technology Magazine, IEEE, vol. 4, no. 2, pp. 52–64, Jun. 2009.
[3] J. D. Howard and T. A. Longstaff, ―A Common Language for Computer Security Incidents,‖
no. Sandia Report: SAND98-8667, 1998.
[4] U. E. Larson and D. K. Nilsson, ―Securing Vehicles against Cyber Attacks,‖ in CSIIRW ’08:
Proc. of the 4th annual workshop on Cyber security and information intelligence research. New
York, NY, USA: ACM, 2008.
[5] D. K. Nilsson and U. E. Larson, ―A Defense-in-Depth Approach to Securing the Wireless
Vehicle Infrastructure,‖ Journal of Networks, vol. 4, no. 7, pp. 552–564, Sep. 2009.