1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
---
title: Overview
---
Modern cars have become a lot more technologically sophisticated and different
than those of the past. We are seeing a wider range of new features and
functionality, with a lot more complex software. It is fair to say that the cars
being introduced to the market today have much more in common with computing
devices like cell phones, than their predecessors did. Modern car manufacturers
are also integrating support for a broad range of communication technologies for
these “connected” cars. With the advent of such vehicles, Linux has become a
natural choice for the software platform, with Automotive Grade Linux as a
promising example.
From a security point of view, the remote capabilities of a connected car
results in a much larger attack surface. This opens a whole new world of
security vulnerabilities that need to be considered during the architectural
design. History shows that physical access to a device is sufficient for a
hacker to gain root privileges. This makes the car a hostile environment.
The Security Blueprint documents the security features that are included as part
of Automotive Grade Linux (AGL) and identifies areas that need to be addressed
from a security perspective as part of AGL. It also gives guidance around
existing technologies and solutions.
Security domains will allow us to create a set of tests verifying the security
of Automotive Grade Linux.
This document is firstly based on an existing AGL security-blueprint.
**For security to be effective, the concepts must be simple. And by default,
anything that is not allowed is forbidden.**
We will cover topics starting from the lowest level (_Hardware_) up to the
highest levels (_Connectivity_ and _Application_). We will move quickly on
_Hardware_ and _Connectivity_ because this is not supported at our level.
Solutions of connectivity problems concern updates and secured settings while
hardware securing is related to the manufacturers.
## Adversaries
Adversaries and attackers within the Automotive space.
- Enthusiast Attackers
Enthusiast attackers have physical access to the Engine Control Units (ECUs) at
the circuit board level. They can solder ‘mod chips’ onto the board and have
access to probing tools. They also have information on ECUs that have been
previously compromised and have access to softwares and instructions developed
by other members of car modification forums. The goal of the enthusiast hacker
could be, but is not limited to, adding extra horse power to the car or hacking
it just for fun.
- Corrupt Automotive Dealers
Corrupt automotive dealers are attackers that have access to the same
capabilities as enthusiasts, but also have access to the car manufacturer’s
(OEM) dealer network. They may also have access to standard debugging tools
provided by the car manufacturer. Their goal may be to support local car theft
gangs or organized criminals.
- Organized Criminals
Organized criminals have access to all of the above tools but may also have some
level of control over the internal network at many dealerships. They may have
hacked and gained temporary control of the Over-The-Air (OTA) servers or the
In-Vehicle Infotainment (IVI) systems. This is very much like the role of
organized criminals in other industries such as paid media today. Their goal is
to extort money from OEMs and/or governments by threatening to disable multiple
vehicles.
- Malware Developers
Malware developers have developed malicious software to attack and compromise a
large number of vehicles. The malicious software is usually designed to spread
from one vehicle to another. Usually, the goal is to take control of multiple
machines and then sell access to them for malicious purposes like
denial-of-service (DoS) attacks or theft of private information and data.
- Security Researchers
Security researchers are ‘self-publicized’ security consultants trying to make a
name for themselves. They have access to standard tools for software security
analysis. They also have physical access to the vehicle and standard hardware
debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to
publicize attacks for personal gain or just to gain personal understanding with
a sense of helping make things more secure.
## Attack Goals
In today’s connected vehicle, more and more functionality is moving to software
control, meaning that the threat of attack becomes greater and greater. We see
car features like navigation and summoning, car access/engine start, and
motor/ECU upgrades all controlled through software and connections to the cloud.
The risk of attack is high because there are high value targets in play.
Here, we outline some of the major threats categories along with some sample
attackers, example attacks, and a relative importance. These threat categories
are intended to be general examples. There can be many nuances to threat types.
Additionally, there can be many sub-attacks that eventually lead to these higher
level attack goals.
| Threat Category | Sample Attacker | Example Attacks | Relative Importance |
|-------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
| Vehicle theft | Individual, organized criminals | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity) |
| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury) |
| Vehicle hacking | Vehicle owner, competitor | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) |
| Sensitive asset theft | Organized criminals, blackmailers | Steal credit card numbers, health information, camera data, steal bandwidth | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later) |
The Automotive Grade Linux (AGL) initiative builds upon open-source software
including Linux and Tizen to offer a flexible application framework. However,
the security provisions of the app framework, Cynara, and the security manager
only go so far in keeping the biggest threats at bay. As experience has shown,
providing a constrained app (like that in the Android Open Source Platform) and
store development flow, signature verification, DAC sandboxing, and MAC (SMACK)
controls over the platform can have a certain amount of success with the
security of the system. However, the openness of the system invites many
researchers, hobbyists and hackers and financially motivated attackers to
compromise the system for their own gains.
As AGL arrives on modern automobiles, this is inevitably inviting many capable
actors to modify, attack, and compromise these well thought-out systems and
their applications. With concerns like safety and security, the auto industry
cannot afford to go the way of consumer devices like phones and tablets where
security problems are encountered on a frequent basis. It is imperative to use a
layered approach and defense-in-depth to protect the system from inevitable
attack.
## Assets and Security Categorization
This section outlines some of the assets that are likely to be found in the
vehicle and their relative sensitivity from an attack point of view.
Additionally, the final column on the right lists some of the recommended
protection types that can be applied to these types of assets (Note that the
empty cells refer to the cells above them). A good protection approach will give
priority to the most sensitive assets, using a defense-in-depth approach to
cover these assets. Less sensitive assets are treated at a lower priority,
typically protected with fewer protection techniques. A more fine-grained
prioritization of the the assets in a concrete vehicle network can be achieved
with detailed threat analysis which considers the topology of the vehicle
network and access-controls that are in-place. e.g. the EVITA framework for
attack trees.
| Asset Category | Examples | Sensitivity | Recommended Protection Types |
|-------------------|--------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Software | ECU software, infotainment software, OS images | Critical | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS |
| Car Access | Biometric data, car keys | | |
| Payment Data | Credit cards, User profile critical data | | |
| Recordings | Internal camera recording, internal audio recording, external camera recording | High | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation |
| User Profile | Usernames and passwords, customization, calendar, contacts | | |
| Location | GPS coordinates, vehicle usage data | | |
| Purchased Content | Video, audio, licenses | | |
| Teleconference | Chat, audio, video | Medium | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission |
| Vehicle data | Vehicle info, sensor data | | |
| Navigation data | Static and dynamic maps | | |
| 3rd party data | Home automation commands, cloud game data | | |
## Hardening term
The term Hardening refers to the tools, techniques and processes required in
order to reduce the attack surface on an embedded system, such as an embedded
control unit (**ECU**) or other managed devices. The target for all hardening
activities is to prevent the execution of invalid binaries on the device, and to
prevent copying of security related data from the device.
## AGL security overview
AGL roots are based on security concepts. Those concepts are implemented by the
security framework as shown in this picture:
--------------------------------------------------------------------------------
# Acronyms and Abbreviations
The following table lists the strongest terms utilized within all this document.
| Acronyms or Abbreviations | Description |
|---------------------------|-------------------------------------|
| _AGL_ | **A**utomotive **G**rade **L**inux |
| _ECU_ | **E**lectronic **C**ontrol **U**nit |
--------------------------------------------------------------------------------
# References
- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html).
- _http://
docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_
- **[2017]** - [kernel
security](https://www.kernel.org/doc/Documentation/security/).
- _https:// www.kernel.org/doc/Documentation/security/_
- **[2017]** - [Systemd integration and user
management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf).
- _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_
- **[2017]** - [AGL - Application Framework
Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf).
- _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_
- **[2017]** - [Improving Vehicle
Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf).
- _https://
access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_
- **[2016]** - [AGL framework
overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html).
- _http://
docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_
- **[2016]** -
[SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf).
- _http://
iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_
- **[2016]** - [Linux Automotive
Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf).
- _http://
iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_
- **[2016]** - [Automotive Security Best
Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf).
- _https://
www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_
- **[2016]** - [Gattacking Bluetooth Smart
Devices](http://gattack.io/whitepaper.pdf).
- _http:// gattack.io/whitepaper.pdf_
- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack
Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf).
- _http://
www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_
- **[2015]** - [Security in Automotive Bus
Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf).
- _http://
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_
- **[2014]** - [IOActive Remote Attack
Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf).
- _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_
- **[2011]** - [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data
communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf).
- _https://
media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_
- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack
Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf).
- _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_
- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in
Modern Cars](https://eprint.iacr.org/2010/332.pdf).
- _https:// eprint.iacr.org/2010/332.pdf_
- **[2010]** - [Wifi attacks wep
wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf).
- _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_
- **[2008]** -
[SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf).
- _http://
schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_
|
