White papers on Connected Vehicles on Security & Safety aspects, Vulnerabilities, impact on socio-economic life of People Please go through this to get a glipse of the facinating opportunities and potential work streams.

1. Connected Vehicles: An Overview on Security, Vulnerabilities and Remedies
Connected Vehicles – Some not so Great Stories
We all heard of July 2015 story where Ethical Hackers, took control of a 2014 Jeep Cherokee’s steering
remotely, even turning off the car’s transmission and drove it into a ditch. It led to recall of 8,000 Jeeps
(2015 Renegades). Similarly, August 2015 saw, researchers taking control of a Tesla Model S and turing
it off at low speed.
More server and tragic, in May 2016, a driver was killed in an accident involving autonomous feature
guided car. In a more controlled environment, Tesla’s Bug Bounty Program in September 2016
discovered a major security flaw. In February 2017, a “simulated hack” reportedly disabled a number of
different Connected Vehicles of different models in UK.
Recent reports on thefts using Remote Keyless Entry vulnerabilities, amplifying the generated signals or
intercepting the door-opening code for later playback were common sometime back.
But Evolution happens with history of Bad Stories
Just like any new technology, like Smart cards, its all about consumer trust. If people trust their connected
car—to keep them safe, to make their lives easier, and to treat their information appropriately— the may
willingly give up their information. Likewise, they expect their data to remain private and secure,
Vulnerability Areas
Relatively common features such as
1. Remote Key and Keyless Access
2. Bluetooth Connectivity (Chesterfield County municipality, VA, forbids Bluetooth in Govt. vehicles)
3. OBD Ports
4. Wi-Fi, DSRC, Cellular, NFC connection
5. Unauthorized Infrastructure Signaling
All above could all contribute to the vulnerability of a vehicle, forming part of a potential “attack surface”.
Even over-the-air (OTA) updates to close the vulnerability are vulnerable to hacker target. Like what we
saw in Jeep’s case, sending a USB stick with self-installing firmware updates to the user, or doing
updates only in secure locations by the car dealer, is often the best solution.
It isn’t just the electronic control units (ECUs) deep within the vehicle itself that can be dangerous if
hacked. Instead, relatively harmless appearing Infotainment unit hacking can kill if the driver is distracted
or surprised at the wrong time. Its an easy target due to the connectivity it requires from various web
services (Weather, Traffic, Streaming Audio etc). All it takes is a single vulnerability (e.g., misconfigured
server, unencrypted API call) for an attacker to exploit the rest of the system.
Devices plugged into a vehicle’s on-board diagnostics port (OBD-II) may contain a GPS receiver, cellular
chip etc. They can communicate with vehicle’s CAN bus as well as with service provider to share data on
vehicle’s operation. A remote, unauthenticated attacker may be able to execute arbitrary code on the
device causing vehicle damage or injuries if the device is compromised. Enabling connectivity to once-
closed CAN bus can result in harmful effects if security engineering principles are not properly applied.
Reasons for such Vulnerabilities

2. In 1st phase of Connected Vehicle evolution, automakers added more and more technology components,
but soon realized that they had to protect their systems since secure architecture was not at fore front
while designing these systems. Instead what was the easiest and cheapest way to do that? Add layer
over layer, patch over patch of security across a single, flat network.
That is a problem. In a connected car, all systems share a network, meaning if you access one you may
be able to access them all. In real life, this means a hacker might be able to expose vulnerabilities in a
driver’s smart phone to steal information from vehicle systems the device is connected to or even take
control of a car’s operational systems, like its engines and brakes.
Why there are Concerns for Vehicle’s Telematics Data
Security and privacy concerns surrounding connected car technologies affect not only the individual
consumers but also corporate, municipal, law enforcement and other business and government interests.
Telematics systems that track and wirelessly communicate the location, movement, behavior and health
of a vehicle in real time are most vulnerable components of the Connective-Vehicle eco-system.
Following are some of the example attacks. Results can vary from controlling vehicle’s non-safety-critical
operations, disabling critical or non-critical systems controls to potentially loosing total control.
Attack
 Exploit an unauthenticated API (e.g., remote features) used in a CV
 Exploit a vulnerability in a mobile application used to connect to a CV
 Monitor a CV’s messaging traffic for an extended period of time
 Knowledge of vehicle location, regular routes taken, and duration of stay.
 Coordinated attack on vehicles & infrastructure, Denial of Service, Internet & wireless (jamming)
 Ransomware restricting the use of features or using as DDoS attack node against infrastructure
 Exploit a CV’s weak cryptographic features or unchanged/weak passwords
 Spoof the vehicle’s sensors (e.g., LIDAR, GPS)
 Reverse engineer CVs firmware, modify MCUs to bypass security controls or change functionality
 Physically interface with a CV (e.g. via its USB port) to install malware
 Learning protected information e.g. Private keys using cryptanalysis of algorithms/signed
messages
 Re-playing system message at a different (than original) time and/or location.
 Modifying the sensor inputs on a single or multiple vehicles before the vehicle uses them to
generate and send system messages (For example, by GPS spoofing)
Recommendations for securing the Connected Vehicle Environment
Securing the overall ecosystem of CVs requires coordinated planning and execution across multiple
stakeholders like OEMs, suppliers, aftermarket developers, Controlling & Compliance authorities or
Government Institutions. Guidance is needed at various layers of the technology stack on:
 Security of the CV platforms, which includes:
• Protection of control systems (CANBus, OBD-II port access, OBE)
• Protection of Infotainment Systems
• Protection against use of insecure third-party devices and applications
• Recommendations about software security engineering
• Hardware security controls (e.g., to protect MCUs)
• Software Maintenance
 Security of the smartphone applications interacting with vehicles and communication systems
 Events monitoring , Authentication/Authorization & cryptographic key management methods
 Security of messaging and communication protocols for interaction (e.g., DSRC, cloud , 5G)

3. Recommended Security Counter Measures
 Key Management, Crypto Modules, Libraries and Protocols
 Strong random number generators (RNGs)
 Protections for cryptographic keys including secure storage and Zeroization capability
 Support for key Transfer & management and management of certificate trust anchors.
 Root chain validation for the certificate issued by any trusted party.
 Hardware Security Modules (HSMs) and tamper protection.
 Bluetooth Low Energy (BLE) protocol offers flexible options for pairing devices, including a
mode that requires mutual authentication. Designs must include secure pairing mechanisms.
 Strong Segmentation, Secure Updates & Data Integrity
 Multiple CAN busses separating safety-critical features (brakes, lane detection) from non-
safety-critical features (like door controls, lights).
 Secure Update Processes & Recovery for Failed Rollbacks
 Maintaining data integrity (e.g. Vehicle readings) to avoid spoofing/manipulation.
 Using pool of certificates that digitally sign all message traffic originating from an OBE.
 API Security Guidelines for authenticating transactions, encrypting and integrity checking.
 Access Control with the concept of “least privilege” and ‘need to know’ or ‘need to have’
 Mobile Application Security Certificate pinning to prevent man-in-the-middle (MITM) attacks
over untrusted networks.
 Interface Filtering
 Filtering of all interface traffic
 prevention of malformed messages from being transmitted
 Defining and bounding the data types which can be included in messages.
 Compromise or Misbehavior Detection
 Who is responsible for misbehavior detection?
 Can APIs support new methods for communicating misbehavior?
 Monitoring of driver habits using Pseudonym Certificate Authorities and specialized devices
like Location Obscurer Proxies (LOPs).
 Continued Research and Development
 BlockChain as an alternative mechanism for applying integrity and authenticity protections
like Guardtime’s Keyless Signature Infrastructure (KSI).
 Evaluation of Certificate Transparency (CT) logs which can help certificate authorities (CAs)
determine if certificates have been mistakenly issued or maliciously used
 Analytics on
o Safety data (edge cases, near-misses, early warning, crash reconstruction)
o Maintenance and monitoring (OTA firmware/software updates, prognostics)
o Traffic operations (Speed harmonization, signal priority, routing, incident management)
o Situational awareness (HD maps, objects and events, cooperative localization)
Areas needing Attention due to such Vulnerabilities
 Vehicle to wider Network: Encryption, VPN, Secure Tunnel to OEM
 In Vehicle Protection: Firewall, Intrusion Prevention, Anti-virus/Malware protection
 On Demand Secure Connectivity: V2V, V2I, V2X

4.  Easy of Deploy and to Manage: Centralized Identity and Policy Management, Authentication,
Authorization, Accounting
Technical challenges
Some of the obstacles assessed overtime for CV eco-system to overcome are:
 Testing every conceivable scenario
 Understanding unusual situations
 Cybersecurity – the vehicle must be impregnable
 Interaction between driver, vehicle and eco-system
 Liability, both civil and criminal, for the crashes when the car is in control
Data Ownership and Regulations
In this era of heightened technical advancement, personal data is particularly sensitive, as it is subjected
to data protection legislation. Especially Telematics data which creates understandable concerns about
whether third-parties will have equal and open access to this data at little or no extra cost.
 An innocent e-Com application onboard car Headunit, may be tuned to exchange some corporate
information, work-related communications and financial info like credit card information
 An individual vehicle’s control systems can be targeted or chained in an attack involving personal
information of drivers and passengers.
With increasing connectivity and integration among the connected car, other devices and infrastructure,
vehicles have access to volumes of information. With loads of data being collected, Automakers & OEMs
face new set of challenges about data usage and ownership. What data to collect and what to not, what
may need a consent? Any laws or regulations regarding allowed data uses?
Also the important question, where does all of this data go? Complexity gets further magnified by multiple
clouds being interconnected. The data could very well gets shared across different industry stakeholders
(and their respective clouds) like Carmakers, Content delivery entities, advertisers, regulatory or
governmental organizations.
The OEM or a carmaker, may well be responsible to the consumer for the use and distribution the data.
One day, the Consumer may well ask to revoke the right to use such data, in that case it must be revoked
across the ecosystem. This is huge, since it means the whereabouts of this data, the entire trail much be
known so that it can be managed.
Author feels that in 2nd phase of Connected Vehicle Evolution, all clouds of concerns will be clear
clearing a way for 3rd phase of Real world of Connected and Autonomous vehicles.