Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Towards Enhanced Security for AutomotiveOperating Systems
by
Maksym Hryhorenko
A thesissubmitted to Florida Institute of Technology
in partial fulfillment of the requirementsfor the degree of
Master of Sciencein
Information Assurance and Cybersecurity
Melbourne, FloridaDecember, 2018
c⃝ Copyright 2018 Maksym Hryhorenko
All Rights Reserved
The author grants permission to make single copies.
We the undersigned committeehereby approve the attached thesis
Towards Enhanced Security for Automotive Operating Systemsby
Maksym Hryhorenko
William Allen, Ph.D.Associate ProfessorComputer Engineering and SciencesCommittee Chair
Heather Crawford, Ph.D.Assistant ProfessorComputer Engineering and SciencesCommittee Member
Veton Kepuska, Ph.D.Associate ProfessorComputer Engineering and SciencesOutside Committee Member
Philip Bernhard, Ph.D.Associate ProfessorComputer Engineering and SciencesAcademic Unit Head Department
ABSTRACT
Title:
Towards Enhanced Security for Automotive Operating Systems
Author:
Maksym Hryhorenko
Major Advisor:
William Allen, Ph.D.
Modern automotive infotainment systems are represented by highly complex compo-
nents with broad functionality and network capabilities. As a result, they are becoming
more exposed to the outer world, thus turning into potentially lucrative targets for
remote cyber attacks. In the worst case scenario, an attacker could gain complete
control over critical vehicle’s systems, for instance, steering, braking, engine, etc. This
thesis proposes security hardening features based on ARM’s TrustZone technology for
infotainment systems that ensures confidentiality and integrity of critical applications.
In addition, we present a technique that allows to mitigate the impact of certain attacks
on the car’s internal network. In contrast to existing solutions, our security features do
not require separate hardware and can be implemented on the same system-on-chip as
an infotainment system. Finally, we evaluated the implemented approach and demon-
strated its capabilities to successfully mitigate potential attack vectors created by a
compromised operating system, specifically, fake input injection, screen capture, and
overlay attacks.
iii
Table of Contents
1 Introduction 1
1.1 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 8
2.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 ARM TrustZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 TrustShadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Automotive Grade Linux . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 i.MX 6 Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Control Area Network Standard (CAN) . . . . . . . . . . . . . . . . . 13
2.6.1 FlexCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Design 17
3.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Trusted Execution Environment . . . . . . . . . . . . . . . . . . . . . 18
3.3 Secure User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Secure Network Channel . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 CAN Bus Communication Routing . . . . . . . . . . . . . . . . . . . 23
iv
4 Implementation 26
4.1 Framework for Embedded Linux Development . . . . . . . . . . . . . 26
4.2 TrustZone Address Space Controller . . . . . . . . . . . . . . . . . . . 28
4.3 Secure User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Secure Network Channel . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 CAN Communication Routing . . . . . . . . . . . . . . . . . . . . . . 32
5 Evaluation 33
5.1 Test Bed Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Features Overview and Security Evaluation . . . . . . . . . . . . . . . 34
6 Conclusion 40
A Yocto Layers 45
B Framebuffer Structures 46
C Input Devices 49
D Touch Logger 52
E FlexCAN Message Buffer Data Structure 56
v
List of Figures
1.1 CAN Bus interconnectivity and entry channels . . . . . . . . . . . . . 3
2.1 FlexCAN message buffer . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 CAN frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 FlexCAN message buffer [24] . . . . . . . . . . . . . . . . . . . . . . 16
3.1 System’s architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Secure display service setup routine . . . . . . . . . . . . . . . . . . . 21
3.3 Secure network channel flow chart . . . . . . . . . . . . . . . . . . . . 23
3.4 CAN routing flow chart . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 i.MX6 SabreSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 AGL interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4 Secure UI Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5 CAN Bus Message Injection . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 CAN Bus Attack Filtered . . . . . . . . . . . . . . . . . . . . . . . . 39
vi
List of Abbreviations
AGL Automotive Grade Linux
ARM Advance RISC Machine
CAN Control Area Network
ECU Electronic Control Unit
HVAC Heating, Ventilation and Air Conditioning
IVI In-Vehicle Infotainment
LVDS Low-voltage Differential Signaling
MMU Memory Management Unit
SDK Software Development Kit
SoC System-on-Chip
TEE Trusted Execution Environment
TZASC TrustZone Address Space Controller
UI User Interface
viii
Acknowledgements
I would like to express my profound gratitude to my thesis advisors Shengzhi Zhang and
William Allen for remarkable support they provided me during the research. They con-
stantly pointed me towards the right direction, supplied me with highly useful research
material and presented valuable comments on this thesis.
I would also like to thank my parents and brother for providing me with unfailing
support and continuous encouragement throughout my years of study and research
and during the whole writing process of my master’s thesis.
ix
Chapter 1
Introduction
Contemporary automotive systems are represented by the tremendous number of com-
ponents and microcomputers. In order to fully utilize the system’s technical capabilities
and ensure efficient communication, the Control Area Network (CAN) bus standard
was developed. CAN is a robust message protocol, that implies a connection of all
car systems to a single bus. Hence, every node in the automotive system’s network
can receive from as well as send messages to every other component. CAN network
messages can be informative, which provide state of a certain vehicular unit, e.g. dash-
board unit outputs vehicle tires status by reading tire pressure indicators, or control,
which change the state of a component, e.g. Adaptive Cruise Control unit sends the
command message to braking system in order to reduce vehicle’s speed. Although
CAN communication standard offers significant benefits to efficiency, extensibility and
cost of automotive systems, it creates dangerous attack vectors, where a single com-
promised unit opens access to critical vehicle systems, for instance, engine control unit,
steering or braking system [1].
1
1.1 Threat Model
Traditionally, the node with the richest network capabilities appears to be the weakest
link of a system from a security perspective. In case of automotive security, the
most exposed element is In-Vehicle Infotainment (IVI) — a sophisticated, feature-rich
component that comprises a plethora of hardware and software solutions, including
audio and video entertainment, information display with vehicle’s condition, radio,
navigation, air-conditioning. In addition, in modern cars can also include Bluetooth
and USB connectivity (e.g. with a smartphone), in-car internet (through cellular or
satellite network), Wi-Fi, integration with mobile devices, in-house applications and
widgets (e.g. weather, news, browser), parking assist, braking assist. IVI systems are
continuously being improved and expanded by car manufactures. Figure 1.1 shows
interconnectivity of components in the car’s CAN network and entry channels for a
remote attack.
More and more automobile’s Electronic Control Units (ECU) become accessible through
infotainment system to facilitate driver’s experience. Unfortunately, additional func-
tionality exposes more car critical components for potential malicious attacks. In ad-
dition, considering network connectivity capabilities of IVI, attacks could be executed
not only through physical access to the vehicle, but remotely as well.
In this way, in-vehicle infotainment security raises significant concerns in the automotive
industry. Compromised IVI head unit, with escalated privileges, is capable of accessing
a vehicle’s internal bus as well as injecting malicious CAN control messages, thus
manipulating critical ECUs. Table 1.1 outlines /potential malicious impact on an
automobile in the case when a compromised node takes control over the CAN bus.
In [2], Checkoway et al. explored attack surface in modern automotive systems. The
2
Figure 1.1: CAN Bus interconnectivity and entry channels
authors discovered and presented an assembly of vulnerabilities in various vehicle’s
ECUs. For every scenario, complete control over the vehicle was obtained. Vulnerable
entry channels include a media player (malicious WMA file), Bluetooth (through the
paired and unpaired device), diagnostic PassThru device, telematics (aqLink protocol),
a cellular network, an infected smartphone connected to the car.
However, the strongest motivation for this thesis was the presentation on remote car
exploitation by Charlie Miller and Chris Valasek [3]. The authors conducted a com-
prehensive security assessment of genuine, recent for those time, 2014 Jeep Cherokee,
that was equipped with a plethora of features, including driving assist, collision warn-
ing, lane departure warning, park assist. The infotainment system of the car utilized
Uconnect radio, that encompassed navigation, Wi-Fi connectivity, apps and cellular
3
ECU Possible Malicious Impact
Driving Assist Control car’s steeringEngine Control Unit Shutdown or start the engineAdaptive Cruise Control Manipulate acceleration and brake systemsAir Conditioning Change the intensity and temperature of the cli-
mate control systemSensors Falsified readings can indirectly impact on systems,
e.g. light sensors can enable headlights, rains sensor— windshield wipers
Navigation Replace routes, poison a maps database, retrievecar’s location
Infotainment Manipulate media system, spoof vehicle conditionvalues, steal credentials (e.g. credit card)
Table 1.1: Various malicious impact on automotive systems
communication. In addition, Uconnect head unit was connected to the CAN bus and
contained hardware and software which enables communication with other car mod-
ules. The authors discovered and successfully exploited vulnerable D-Bus service of
infotainment module with command injection attack. Further, they advanced the ex-
ploit by updating the firmware of CAN gateway of the infotainment, as a result, they
were capable of sending remote CAN control sequences and manipulate automobile’s
system components.
1.2 Existing Solutions
The topic of car security and, specifically, security of bus systems is been actively
explored by the research community.
4
One of the solutions, proposed by Hamad et al. in [4], describes a communication frame-
work for a network of embedded systems with microkernel-based architecture. The
approach implies that every component in a car network is running on a microkernel-
based operating system. The authors implemented a communication module (firewall)
that defines all permitted communication paths between ECUs as well as ensures fine-
grained based access control and secure device communication through authorization.
Combination of ECUs running on microkenrel-based OS with comprehensive process
isolation and a separate firewall module provides a strong security model for automotive
systems. Unfortunately, microkernel suffers from inter-process messaging overhead and
as a result slower than the ubiquitous monolithic kernel, especially with sophisticated
and feature-rich components, e.g. infotainment systems, running on top of it. In ad-
dition, this security mechanism requires an installation of the external component in
CAN network — firewall module — for each ECU, thus complicating implementation
on existing cars.
Other security schemes rely on encryption and integrity checks of CAN messages. One
of such solutions was proposed by Van Herrewege et al. in [5]. The authors developed
and presented an authentication protocol based on preshared keys, HMAC and mes-
sage id tracking. Every node in the network assumed to have predefined 128 bit key
storage, that was assigned during the vehicle’s development phase and deployed in a
tamper-resistant private storage. This security model allows to mitigate spoofing and
replay attacks. Nevertheless, this solution is not capable of protecting components
that require a connection with the compromised node by design, e.g. climate control
and compromised infotainment unit. Moreover, due to the overhead of software im-
plementation of cryptographic primitives, the proposed approach is not practical for
embedded systems with real-time requirements.
5
Therefore, this thesis proposes a different method of securing automotive systems,
that is primarily focused on hardening of its infotainment component. The proposed
approach utilizes hardware hypervisor technology on ARM processors — TrustZone
— and can be built on top of the traditional monolithic kernel, thus compatible with
most available entertainment OS. The solution ensures, that even compromised kernel
(e.g. rootkit) would not be able to tamper memory of critical applications running in
this environment, for instance, Heating, Ventilation and Air Conditioning (HVAC) or
payment module (for in-car app purchases).
1.3 Proposed Solution
Four security hardening features are presented in this thesis: a trusted execution en-
vironment, secure user interface, secure network channel and CAN communication
routing.
Trusted Execution Environment (TEE): In case of compromised OS, memory of
critical applications should be protected from accessing and tampering by a malicious
component with elevated privileges. The solution is heavily based on TrustShadow
security system [6], that was adapted for newer Linux kernel (from 3.18 to 4.8) version
and automotive Linux distributive (AGL).
Secure user interface (UI): This component provides a trusted path between user
and applications which are running in TEE. In this thesis, the prototype of secure UI
is presented by a confirmation window that always appears on top of the home menu
screen and protected from overriding and overlaying by compromised OS.
Secure network channel: In order to reduce trusted computing base (TCB), Trust-
6
Shadow relies on OS components, including network interaction. Thus, protected
applications will expose critical data while utilizing the network interface provided by
OS drivers. To prevent this, a secure network channel was developed, that ensures
confidentiality and integrity of data while using the untrusted network driver of OS.
CAN communication routing: To ensure only allowed operations are requested by
IVI system, filter component was implemented in TEE as well as untrusted OS was
isolated from direct access to the CAN bus.
The rest of the paper is organized as follows: Chapter 2 presents background infor-
mation on technologies and hardware that were used for the research. Chapter 3
describes architecture and design of the solution. Chapter 4 explains implementation
details. Chapter 5 presents performance evaluation. Chapter 6 concludes and summa-
rizes proposed security model.
7
Chapter 2
Background
In this chapter, we will overview prior research on topics of automotive and industrial
security, filtering of malicious messages in networks, least privilege security principle,
and hardware-enforced isolation. In addition, we will describe different technologies,
software and hardware that were utilized in the design and implementation of the
proposed security model. In particular, the topics of interest are:
ARM TrustZone a hardware-enforced security mechanism;
TrustShadow a particular implementation of security solution on top of TrustZone;
Automotive Grade Linux fully open source Linux distribution and framework de-
signed for automotive systems.
i.MX 6 a developer’s board with enabled TrustZone support.
8
2.1 Related Work
Concerns regarding automotive security are frequently raised by the research com-
munity, as new attack vectors and security flaws are being discovered in automobile
systems. In the paper [7], Wright overviewed attacks on vehicle systems which were
accomplished by injecting malicious code into the on-board computer diagnostics port.
The results of this attack were severe, as the research team could remotely control a
car, start and stop the engine, lock and unlock doors through Bluetooth and cellular
services. The author concluded, that due to the unrestricted nature of the CAN bus,
every connected device with wireless capabilities presents a potential entry point for re-
mote attacks. Eckhoff and Sommer raise concerns of security and privacy preservation
in current and future standards of vehicular networks in [8]. In the paper [9], Whalen
et al. presented their framework for the development of a secure architecture for vehic-
ular systems, specifically for military unmanned aerial vehicles. Their solution is based
on microkernel OS architecture and efficient domain-specific programming languages
(Ivory) which guarantees the absence of certain classes of memory errors, e.g. overflow
and underflow, as well as provides significant integration with cryptographic libraries.
Security in industrial control systems (SCADA) is a related to vehicle security topic as
the Modbus protocol, that is commonly used in such systems, closely resembles the
CAN bus. In their research [10], Gao and Morris described a plethora of cyber attacks
on SCADA systems, including response and command injections and denial of service.
In addition, the authors presented rules for the SNORT intrusion detection system to
mitigate the whole set of attacks.
Hardware-enforced security and Trusted Platform Module (TPM) use cases and benefits
for security in embedded systems are discussed by Osborn and Challener in [11]. In the
9
paper [12], Asokan et. al introduced multiple security architectures and approaches for
mobile platforms using hardware-enforced isolation that can provide a trusted execution
environment for critical applications and libraries.
The topic of incoming and outgoing message filtering is thoroughly discussed in [13]
and [14].
Lampson et. al introduced the theoretic access control model with enforcement of least-
privilege principal for nodes in a distributed system [15]. In [16], Saltzer and Schroeder
presented a detailed tutorial into the mechanics of information protection, in which they
described different approaches for access control, authorization, least-privilege principle
and other security mechanisms.
2.2 ARM TrustZone
TrustZone is a hardware architecture, implemented on System-on-Chip (SoC) devices
with ARM processors, that provides a security framework to counter many threats in
embedded systems. The primary feature of TrustZone is partitioning of all hardware and
software resources in one of two worlds — secure, for security subsystems and sensitive
assets, and normal, for everything else. Both worlds have independent memory address
space. The TrustZone hardware architecture ensures that no assets in the secure world
can be accessed from the normal world [17]. This isolation provides protection to
trusted applications against non-trusted, which were installed by user and run in the
normal OS.
TrustZone enabled processors can run in two states: secure and non-secure. In non-
secure state processor can access assets designated only for the normal world. In secure
10
— both secure and normal world. To support code execution from two worlds in time-
sliced fashion, ARM processor has specifically allocated physical core. Access control
is enforced with non-secure (NS) bit — an extension control signal in ARM SoC for
read and write channels on the main system bus. If an application in the normal world
attempts to access protected assets, the operation fails silently or generates an error.
The world switch operation is issued with a smc instruction and is handled through
monitor mode software that saves and restores system state and transfers execution
control. The hardware provides two virtual memory management units (MMU) for
proper isolation of memory address space of both worlds. TrustZone secure world is
booted before the normal OS, thus ensuring proper validation of the kernel image and
preventing an attacker from replacing it with a malicious one [6].
Therefore, embedded systems developers have many security architecture approaches.
Commonly, a secure world is presented by the compact kernel with implemented secure
service, e.g. key management, an online payment module, one-time passwords gener-
ation, secure storage, SSL library, and the normal world with a feature-rich operating
environment that calls services in the secure world.
2.3 TrustShadow
TrustShadow is a security solution that utilizes TrustZone technology to protect legacy
applications from untrusted operating systems [6]. This solution ensures that security-
critical applications will be running in a trusted execution environment isolated from
potentially compromised OS. The key feature of TrustShadow is a lightweight runtime
system that provides a communication bridge between protected applications and nor-
11
mal OS, in particular, its services, e.g. network drivers, IPC, signal handling, libraries
etc. Therefore, any application, that was developed for normal OS can run in the
secure world without source code modifications. TrustShadow was implemented and
tested on i.MX 6 SabreSD developer’s board [6]. It supports Linux Kernel version 3.18.
TrustShadow provides a particularly useful foundation for security solutions based on
Automotive Grade Linux (AGL) distribution and TrustZone enabled hardware as impor-
tant components, e.g. secure monitor and runtime system, is already implemented and
can be reused. Therefore, it was utilized as a framework for security model presented
in this thesis.
2.4 Automotive Grade Linux
Automotive Grade Linux is an open-source infotainment OS and application framework
for automotive systems that is based on Linux Kernel. The primary purpose of AGL is
to provide a common platform that can support car apps from various manufacturers.
Hence, simplifying apps development and creating more opportunities for the vehicle
applications market, similar to the mobile market.
Currently, AGL is supplied with a collection of apps and widgets, specifically media
player, mixer, HVAC, vehicle state info (tire, fuel, speed), phone, navigation, Bluetooth,
apps manager. Moreover, the platform is highly customizable and easily extendable.
AGL is particularly useful as a development platform for the thesis, as it possesses broad
functionality and is well documented. Furthermore, AGL is a promising platform that is
actively supported and promoted by Linux Foundations, as a result, car manufactures
recently started adopting it as their primary infotainment system [18].
12
2.5 i.MX 6 Board
i.MX 6 series is a family of Systems-on-Chip developed by Freescale Semiconduc-
tor [19]. i.MX boards are particularly interesting for the topic’s research as they are
supplied with ARM CPU and, what is more important, its TrustZone feature is unre-
stricted, in contrast to cheaper ARM boards from other manufacturers, like Samsung,
NVIDIA. Furthermore, i.MX series features models that are specifically designed for car
infotainment systems (AI series), that has similar hardware, besides additional media
inputs/outputs and connectors (to CAN Bus etc.), as general purpose boards. Hence,
general purpose i.MX 6 board presents a universal and convenient testing bed.
2.6 Control Area Network Standard (CAN)
The CAN communication protocol is carrier-sense, broadcast message protocol. The
carrier-sense nature implies, that transmitter ensures in absence of traffic in the network
before sending a message. CAN implements collision detection with the help of message
arbitration. Each CAN message type is supplied with preprogrammed identifier field
that defines its priority. Higher priority messages win bus access [20]. Important
features of the CAN protocol are high reliability, due to its ability to detect all single-
bit errors as well as multi-bit errors with sufficient probability, and fault confinement
that prevents a faulty single node from corrupting the network [21].
CAN communication model can be decomposed into three layers: application, data
link and physical (Figure 2.1). Physical layer includes CAN transceivers, connectors
and bus-line. Commonly, twisted-pair copper cables are utilized as a transmission
medium. Next level is presented by Data link layer. Data link protocols (Classic CAN
13
Figure 2.1: FlexCAN message buffer
or CAN Extended) define process data object format — CAN frame — a data unit
on the CAN network. Finally, Application layer is responsible for device addressing,
transportation of data blocks larger than one frame and other high level tasks. Unlike
data link, the application layer is not standardized, thus every manufacturer has its own
implementation, e.g. EnergyBus is used in electric bicycles and pedelecs [22], MilCan
— in military vehicles [23].
Figure 2.2: CAN frame
CAN frame. Structure of data link layer frame is presented in Figure 2.2. The
meaning and purpose of each field is next:
• SOF — start of frame, marks start of message.
• Identifier — defines priority of messages and their function. This field is impor-
tant for our security research, as other nodes identify and process messages based
14
on their ID, e.g. message with ID 01FC controls tachometer, turn signal ID is
05CE (numbers are taken from [3], however, different car models have different
IDs). Lower IDs have higher priority. Precedence is important for CAN messages
to ensure critical systems instant response in case of emergency.
• RTR — remote transmission request, bit is set when node is waiting for certain
information from other node.
• IDE — identifier extension, bit is set if frame format with extended length of
identifier is being used.
• r0 — reserved, not used.
• DLC — size of data being transmitted.
• Data — application data.
• CRC — checksum for error detection.
• ACK — acknowledgement bit. Every node should send a signal that data frame
was received without errors. Otherwise, sender repeats a broadcast.
• EOF — end of frame mark.
2.6.1 FlexCAN
FlexCAN controller is a particular implementation of the CAN protocol on i.MX SoCs
boards. The controller holds queue of up to 64 retrieved messages or messages ready
for sending. All messages have specific format. FlexCAN message buffer structure is
presented in Figure 2.3.
The meaning of each field is next:
• CODE — indicates status of buffer, e.g. 0000 buffer not active/ready, 0100
buffer is active and empty.
15
Figure 2.3: FlexCAN message buffer [24]
• SRR — substitute remote request, same as RTR but used only in extended
format.
• IDE — identifier extension, bit is set if frame format with extended length of
identifier is being used.
• RTR — remote transmission request, bit is set when node is waiting for certain
information from other node.
• LENGTH — size of data being transmitted.
• TIME STAMP — time when message buffer was captured since system boot.
• PRIO — additional local priority.
• Identifier — same as in classic CAN frame.
• Data — up to 8 bytes of data.
In this chapter, we overviewed prior research on the related topics and described tech-
nologies, software and hardware that were utilized in our solution, including ARM
TrustZone, AGL, TrustShadow, i.MX 6 development board and CAN communication
protocol.
16
Chapter 3
Design
In this chapter we will describe overall architecture as well as design details of proposed
security hardening features.
3.1 Architecture Overview
Traditionally, systems, that are based on TrustZone secure architecture, are split into
two layers or worlds: normal, where a feature-rich OS is running, and secure. The
approach closely resembles kernel-user space paradigm, specifically, the secure world
has unlimited access to all devices and memory and at the same time defines access
privileges for the normal world. There are two ways to switch from the normal world to
secure: instruction from the normal world and secure interrupt (interrupt that signals
on protected peripheral). Commonly, worlds communication occurs through a special
piece of software that is running in TEE — monitor. The monitor delegates requests
to various trusted applications or drivers and returns results to the normal world. Data
17
exchange between untrusted and trusted environments occurs through CPU registers
or, if the size of a message is larger than the maximum register’s size (32 bits for ARM
32-bit architecture), through specifically allocated shared memory region.
Figure 3.1: System’s architecture
The architecture, presented in Figure 3.1, specifies components that were utilized in
the solution, their corresponding execution environment and communication. In the
next sections, we will describe the role of each component in security support of the
IVI system.
3.2 Trusted Execution Environment
Trusted Execution Environment (TEE) is provided by TrustShadow [6] system. In gen-
eral, autonomous applications that continuously run in the secure world, e.g. HVAC
front end or a payment module, require CPU time to execute. However, as described
earlier, execution flow transfer is initiated only by the normal world or secure periph-
eral interrupt. Thus, the one way to solve this problem is to protect every hardware
18
component that secure applications could utilize. This approach is highly inefficient
and negates the benefit of small TCB of TrustShadow, as every protected compo-
nent would require implemented driver in the secure world. The solution implemented
in [6] for secure applications implies the creation of its counterpart in the normal world
— shadow — that retrieves CPU time as every other non-secure process. However,
memory of shadow counterpart does not contain any critical data as it resides in the
secure world. Every system call, that shadow makes, is transferred to the secure world
monitor, which then reads memory of secure application, supplies system call with
authentic parameters and delegates it back to OS. After system call completes, OS
transfers control back to the monitor, which then supplies the secure application with
call return results and switches back to the normal world. On the architecture diagram,
shadows are located in user memory space.
3.3 Secure User Interface
In order to ensure to protect user interactions with the secure world from a com-
promised OS while reusing insecure video drivers, we propose a scheme that involves
direct memory access of image processing unit (IPU), so called framebuffer operations.
Framebuffer is a region of RAM containing a pixel map of the display. Therefore,
video output can be manipulated by writing pixel color values into this memory region.
The format of pixels, data structure size, region size depends on displays characteristics
and settings, e.g. display’s resolution or color depth.
Commonly, embedded devices configured to support multiple framebuffers per display
— background and foreground. Our board supports 6 framebuffers as it is supplied with
19
three video output sockets — HDMI and two Low-voltage Differential Signaling (LVDS)
connectors. The multi-layer setup is very convenient in case of two independent video
sources running simultaneously.
For our solution, we decided to utilize foreground framebuffer. Secure kernel does
not support video drivers and is not aware of IPU’s memory region. Thus, it is a
normal world’s responsibility to setup framebuffers including mapping to kernel’s virtual
memory space. After setup was completed, normal world kernel module TZ Support
Driver will extract required characteristics of foreground framebuffer, including physical
address and memory region size, and send them through shared memory to the secure
world. After receiving framebuffer’s information, the secure world sets the specified
memory region as secure-only and setups display service that provides API for simple
graphics drawing. The normal world cannot capture foreground layer and any attempt
to access or change protected framebuffer will result in data abort interrupt, which by
default is not handled and causes a system reboot. After drawing an object on the
foreground layer, execution flow returns to the normal world. Setup routine of secure
display service is presented in Figure 3.2
Transferring touch events: To provide interactivity, display service supports touch
gestures. Touch events are handled by normal OS drivers and coordinates are trans-
ferred to the secure world by support driver. To reduce performance impact, data
transfer and world switch occur only when secure display service is active, in other
words, when there is any active graphics content. To capture touch events, we have
implemented an event sniffer, that reads Linux input device log and notifies TZ support
driver with every update.
After secure display service receives touch coordinates, it confirms whether control ele-
20
Figure 3.2: Secure display service setup routine
ment was pressed or not and executes functions, that were bound to this confirmation
dialogue. Because touch events are handled by the untrusted OS, we considered a
possibility of fake input injection attack by guessing right coordinates. To reduce
the possibility of successful input injection, we adopted a simple CAPTCHA technique.
After user pressed a dialogue button he is required to press on distinguishable confir-
mation icon. This icon is always displayed on a random screen location. In addition, we
limit the number of unsuccessful touches to one to mitigate any brute force attempts.
21
3.4 Secure Network Channel
Even though the memory of trusted applications is protected, the malicious OS still has
an advantage over applications that utilize network capabilities as sent and received
data can be intercepted, tampered by middleware.
A man-in-the-middle attack is commonly mitigated by strong encryption for confiden-
tiality with attached hashed message authentication code (HMAC) for integrity. In
our case, we cannot trust cryptographic (SSL) libraries that are located in the normal
world. Fortunately, i.MX 6 boards have hardware acceleration support for common
crypto algorithms as well as random number generator module. Moreover, the board’s
SDK provides cryptographic APIs.
Therefore, for secure network delegation, trusted OS encrypts payload before transfer-
ring back to the normal world. The algorithm is presented in Figure 3.3 and described
below:
• A Shadow application invokes system call request for the socket send operation.
• OS receives request and transfers system call details to the secure world.
• Monitor checks whether this application requires encryption. If yes, encrypts
payload with public key of the service that this application sends request to.
• Monitor returns encrypted payload to the normal OS.
• Normal OS executes the socket send system call.
Thus, it is possible to implement any secure negotiation sequence, including traditional
SSL/TLS handshake. However, this approach requires to store certificate authority
22
Figure 3.3: Secure network channel flow chart
public keys on protected storage. For simplicity sake, we hard coded secrets in the
secure OS image. Even though public keys do not have to be secret, we need to ensure
their integrity to prevent addition or overwriting with fraudulent certificates.
3.5 CAN Bus Communication Routing
With the capability of TrustZone enabled CPU to set the peripheral device as secure,
we can implement a trusted component that will filter out improper messages from the
malicious IVI system and pass legitimate messages.
CAN is broadcast protocol. Every CAN frame is contains message ID. Connected to
the network devices accept messages with a specific ID and ignore others. Message
acceptance filters are stored on internal memory of CAN interface peripheral. Hence, if
a malicious OS has direct access to the CAN device, it can reprogram filters to accept
all messages and, as a result, sniff the entire network. Moreover, the untrusted system
is capable of queuing any message for broadcast, whether by utilizing drivers or by
23
writing directly into CAN interface registers.
To mitigate such attack, we propose to completely isolate CAN peripheral from the
normal world, yet expose send API through support driver or system call. When appli-
cation issues broadcast request through support driver, the latter stores request details
in shared memory and executes world switch routine. In the secure world, the monitor
passes the request to CAN service which checks the message ID of a frame and ensures
only allowed values are being supplied. After that, service uses CAN driver to send the
message. The CAN routing algorithm for send operation is presented in Figure 3.4
Figure 3.4: CAN routing flow chart
The receiving message routine is more complex. When CAN interface accepts a mes-
sage, it sends interrupt request (IRQ), which CPU then delegates to the specific handler
in the interrupt vector table of OS. In the case of TrustZone systems, both worlds have
their own interrupt vector table (IVT). Secure world handlers have priority. As we pre-
viously mentioned, switch to secure world can occur by a secure interrupt. Therefore,
by specifying function handler for IRQ, masking out all interrupts, except from CAN
interface, by interrupt number, the secure world can receive CAN message, analyze
24
it and then trap this IRQ to normal world’s IVT. This is a complex procedure that
requires deep knowledge of board internals as well as low level programming and due
to time constraints was not implemented in the thesis.
In this chapter, we introduced the architecture of our solution. We described compo-
nents, their structure and role in our security mechanism.
25
Chapter 4
Implementation
In this chapter we will describe implementation details, technologies and frameworks
that were utilized to develop and build our solution.
4.1 Framework for Embedded Linux Development
Building custom solutions for embedded systems and Internet-of-Things products is
not as trivial as building applications on existing operating system. Embedded Linux
systems commonly consist of three components:
• Boot loader — startup code, that powers up and initializes all device’s peripher-
als, verifies hardware’s correct functionality, loads kernel image into memory and
executes its startup code. Common boot loaders for desktop systems are Win-
dows Boot Manager and GNU GRUB. For SoC based systems — Das U-boot.
• Kernel image — core code, an operating system that is running on hardware and
26
provides common services for computer programs.
• Root file system — a minimum set of drivers, libraries, tools that are required
by default applications to run, e.g. keyboard driver, C standard library, python
interpreter.
Hence, the custom embedded system is a complex solution with a plethora of de-
pendencies, most of which required to be configured for compatibility with specific
hardware. In order to simplify setup, management and configuration process, an open
source collaboration project Yocto [25] emerged.
Yocto solution consists of layers. A layer is a collection of closely related compo-
nents [25]. For example, the layer can be a collection of network specific software, like
ftp, http clients and servers (Apache, squid, ncftp, proftpd, tftp), or window composer
software with all supportive components (Wayland composer). Layers can depend as
well as apply patches on top of each other. Depending on layer’s priority, it can over-
write certain parts of components in other layers or completely replace them. When
building a solution, Yocto system pulls source code for each component of the used
layer, resolves dependencies, compiles it, creates file system structure, moves all com-
ponents into designated directories and packs everything into a single image file, that
can be copied on the boot device, e.g. SD card.
For our solution, we utilized ready-to-use Yocto project — meta-agl-demo [26] — with
2017 AGL distributive Daring Dab based on Linux kernel version 4.8. The distribu-
tive has most of AGL applications as well as UI. We created a new layer meta-agl-
trustshadow that replaces Linux kernel with our custom. Layer structure of our Yocto
project is presented in the Appendix A.
27
4.2 TrustZone Address Space Controller
TrustZone Address Space Controller (TZASC) is one of the security mechanisms that
enforces memory access control on TrustZone enabled SoCs. For the ARMv7-A mi-
croarchitecture, this mechanism is presented by the CoreLink TZC-400 Controller
(TZC-400) peripheral [27].
TZASC can be configured to protect physical static address ranges that are accessi-
ble through Static Memory Controller (SMC). These regions correspond to mapped
input/output registers (resources) of peripheral devices [27], e.g. send and receive
buffers of Ethernet interface. Up to 8 configurations can be defined and stored in
TZASC. Each configuration contains region’s base address, top address, enabled flag
and security attribute. Security attribute is effectively a 2 bit field where the first bit
controls read and second write secure global permit — if equals 1 secure operation is
permitted, otherwise not. Secure addresses can be configured during boot or runtime.
TZASC can be manipulated through set of device registers. However, it is tedious and
error prone process. That is why we decided to look for a driver, that could provide
higher level interface to the controller. Fortunately, we found a ready to use implemen-
tation in the ARM Software repository ‘arm-trusted-firmware’ [28]. The driver exposes
useful API for operating TZC, in particular, the function tzc40_configure_region()
allows to program protected memory regions, which could not be accessed by normal
world rich OS.
Hence, any peripheral device with mapped input/output resources can be secured
through TZASC, including, but not limited to, GPU, framebuffers, network card, CAN
interface, keyboard, mouse, USB ports, SD card slots, bluetooth or WiFi adapter.
Nevertheless, TZASC cannot protect itself. That is why ARM implemented TrustZone
28
Protection Controller (TZPC), which is configured only during boot and can secure a
limited number of devices with no granularity (only whole device can be accessed or
not). TZASC is protected by TZPC by default.
4.3 Secure User Interface
Secure UI is a significant component of a trusted path between user and secure world.
Secure UI implementation consists of three steps: retrieve framebuffer characteristics
and forward to secure world, protect framebuffer’s memory, setup touch logger.
Retrieving and protecting framebuffer: To retrieve framebuffer’s data we utilized
Linux fb driver which can be accessed through device file interface /dev/fb* where *
is number of a framebuffer. On our setup, main interface is rendered on fb0 which is a
background framebuffer. For secure world we used fb1 — a foreground. Framebuffer’s
characteristics are stored in kernel data structures — fb_fix_screeninfo, that con-
tains unchangeable characteristics, and fb_var_screeninfo, settings that could be
modified by user. Structures source code is presented in the Appendix B. Particular
fields of interest are:
• smem_start, smem_len — physical address of framebuffer and its size. Thisaddress range should be protected by TZASC.
• line_length — used to calculate byte location for pixel.
• xres, yres — size of screen (1024×768.)
• xoffset, yoffset — offset to visible part of framebuffer, in other words mem-ory that contains pixel values.
• bits_per_pixel — defines color depth of framebuffer, e.g. 8 bits is 256 colors,24 bits is 16.7 million.
29
After framebuffer’s characteristics were retrieved, TZ support driver sent them to secure
world through shared memory.
Low level drawing: Memory address for pixel located at (x,y) coordinates can be
calculated using the next formula [29]:
location = (x + xoffset ) * ( bits_per_pixel / 8) + (y + yoffset
) *
line_length
Now we can set any color by writing integer value that represents color in red, green,
blue format, e.g. 0xFF00FF00 will turn pixel purple with no transparency. Hence,
secure display service can draw arbitrary objects in its own secure framebuffer, which
cannot be accessed and modified by normal world OS.
Touch events: To intercept touchscreen events on Linux we utilized /dev/input/
interface that exposes all input devices presented on the system. Each device is assigned
to one or multiple event files with various numbers. Firstly, we identified which
event handler file is associated with the touchscreen by reading special Linux system
file /proc/bus/input/devices. Our touchscreen is utilizing EETI eGalax Touch
Screen driver [30] as it was the first device presented in the system file Appendix C.
Next, we established logger that continuously reads device events file, parses input
data, scales absolute touchscreen coordinates to current screen’s resolution and sends
them to TZ support driver which then forwards it to TZ display service in the secure
world. To prevent inputs flooding, e.g. during swipe or multi-touch gestures, we limited
the number of sending requests to one per 500ms. In addition, TZ support driver will
not send coordinates to secure world if secure graphics is inactive.
30
4.4 Secure Network Channel
To achieve a trusted path between secure application and cloud services all network
security related logic should be implemented in secure kernel. Our board’s Software De-
velopment Kit (SDK) did not contain any SSL/TLS library. That is why we integrated
third party library Mbed TLS [31]. Mbed TLS was primarily designed as compact
and fast SSL/TLS alternative for embedded devices. Currently is being maintained by
ARM.
Our next step was to proxy all network communications of secure application through
the secure world. This can be achieved by intercepting send() and recv() Linux
system calls, that are used to transport or receive data from the socket. Thanks to
TEE provided by TrustShadow, all system calls are being forwarded to secure monitor
before processing. Hence, we can modify the handlers of TrustShadow TEE. Each
system call has its own unique number which is stored in CPU register r7, thus we can
distinguish which system call was forwarded by checking register’s value. However, with
world switch, processor backups all registers’ values of the normal world and restores
values of the secure world. That is why we utilized global shared memory to transfer
necessary information about application’s state, including its registers’ values, before
world switch.
Finally, in system calls handlers we encrypt or decrypt payload using RSA algorithm.
In our current implementation keys are hard coded and pre-shared for simplicity sake.
In the real world scenario, secure persistent storage for certificate authorities keys is
required. This storage should be protected by TZPC to prevent any modifications by
malicious OS. In addition, an update mechanism should be implemented.
31
4.5 CAN Communication Routing
After the system’s boot, the secure world prepares CAN service. Firstly, system marks
CAN interface as secure by protecting with TZASC physical memory region where
device’s I/O registers mapped and where FlexCAN message buffers are stored. The
physical address is fixed and depends on the board’s model as well as device memory
mapping specifications. Then, system monitor starts forwarding any received CAN
messages from the normal world to CAN service.
In the normal world, an application firstly assembles message buffer, following format
presented in the Appendix E, and then sends CAN message to TZ support driver.
After that, support driver places message buffer in global shared memory and initiates
a world switch. In the secure world, monitor forwards message to CAN service which
checks whether ID is allowed or not. The array of allowed identifiers is hard coded. If
the check was passed, service places the message in sending queue. It is important to
mention that we utilized FlexCAN driver, which is a part of the software development
kit for i.MX boards. The driver provides an interface and notably simplifies interaction
with the device.
In this chapter, we presented the implementation details of our security hardening
mechanisms. We described how memory regions could be protected by TZASC and how
this feature is utilized to provide the secure user interface and CAN message filtering.
In addition, we described the TrustShadow monitor and its role in the implementation
of secure network channel.
32
Chapter 5
Evaluation
In this chapter, we will demonstrate and evaluate the security characteristics of the
implemented solution.
5.1 Test Bed Overview
Our testing setup consists of 5 components.
1. i.MX6 SabreSD (MCIMX6Q-SDB) — multi-purpose development board (Fig-
ure 5.1), with 4 cores Cortex-A9 ARM processor with TrustZone support and
integrated graphics unit.
2. MCIMX LVDS1 — LVDS display with touchscreen.
3. Laptop — the board is connected to the development machine through UART
interface that gives access to the terminal of the board.
33
4. Freescale JTAG debugger — low-level hardware debugger that operates through
JTAG interface.
5. Router — both laptop and board are connected to the same router into the
network. It simplifies file exchange, allows to establish SSH sessions and enables
network booting.
Figure 5.1: i.MX6 SabreSD
AGL distributive is running on top of our configuration. Figure 5.2 shows interface of
home screen and dashboard widgets.
5.2 Features Overview and Security Evaluation
Secure UI: the feature provides the trusted path between a user and the Secure world.
For testing purpose we developed a simple scenario (Figure 5.3): user makes a purchase
34
(a) Home screen (b) Dashboard
Figure 5.2: AGL interface
from a certain application that is running inside compromised OS. We assume that the
payment module was implemented in the trusted world and properly secured. After the
application sends a transaction request to the payment module, the later one setups
confirmation dialog window with transaction details in the protected framebuffer. It
is a user’s responsibility to ensure that transaction details are correct and confirm or
deny the transaction. There are multiple possible attack scenarios for this case.
Fake Credentials: malicious OS can replace application’s payment credentials with
attacker’s. However, the transaction still should be forwarded to the secure
35
Figure 5.3: Test Scenario
world. It is the responsibility of the secure payment module to gather required
information based on receiver’s credentials and output it to the user.
Screen Overlay: malicious OS can activate the framebuffer with higher order that
overlays secure framebuffer. In our setup, we disabled all framebuffers except 0
and 1. Framebuffer 1 is foreground buffer by hardware design and always will be
drawn on top of framebuffer 0. Hence, OS cannot overlay and spoof secure UI
with malicious data.
Screen Capture: malicious OS can capture the content of secure framebuffer. This
attack is mitigated by TrustZone memory protection. Only applications inside
the secure world can read and write to protected memory regions.
Touch Events Injection: in our setup we utilized driver of the untrusted OS to
process touch events, hence, malicious OS can generate touch gestures and send
them to the secure world, thus, imitating user’s input during secure interaction
sessions. Therefore, we implemented CAPTCHA test that was described in 3.3.
CAPTCHA is generated in the secure framebuffer which malicious OS cannot
access to extract its location on the screen. Nevertheless, there is a chance
36
that attacker correctly guesses pixel coordinates and passes the test. Estimated
success rate for random guess attack on screen with 1024×768 pixels resolution
for 60 × 60 pixels sized CAPTCHA is following:
area of CAPTCHAarea of screen = 3600
786000 = 0.004 = 0.4%
Probability can be decreased by multiple orders by increasing the number of
CAPTCHA tests, however, it will reduce the usability of our solution. Confirma-
tion dialog and CAPTCHA are demonstrated in Figure 5.4.
(a) Confirmation (b) CAPTCHA
Figure 5.4: Secure UI Session
Secure Network Channel: All SSL/TLS related functionality for secure applications
37
is implemented in the secure world. Hence, a malicious OS cannot decrypt payload
(if sufficiently strong encryption algorithm has been used), cannot steal authentication
token or modify messages. In the case of impersonation attack, when an attacker tries
to impersonate a legitimate server, authenticity can be validated through a certificate
authority. However, availability of secure network channel cannot be guaranteed as
untrusted OS is responsible for network operations.
CAN Routing: In the current research, we did not conduct testing on the established
CAN network. The setup process for a CAN network is rather complex and requires
multiple CAN compatible devices, which are usually specifically manufactured for in-
dustrial and automotive systems and can be difficult to acquire. In addition, each
device should be properly configured to communicate on certain CAN protocol. Due
to time constraints, hardware limitations, and complexity of setup, we did not test
CAN routing solution. Nevertheless, we described a scenario to demonstrate how this
security mechanism prevents CAN injection attacks. CAN routing creates an additional
layer between the untrusted OS and the CAN bus. If malicious OS has direct access
to the CAN bus it can broadcast and receive any messages. Nodes cannot determine
the sender’s identity and if the received message has valid ID and format the node
will execute this command. The scenario is presented in Figure 5.5. However, IVI
does not necessarily require access to all components on the CAN bus. By applying
least-privilege principle we ensure that only allowed messages are being sent by applica-
tions from untrusted OS (Figure 5.6). It is important to note, that with this approach
attacker still can broadcast certain messages. For example, if IVI has permissions to
control HVAC ECU by design, filtering mechanism will not reject such messages.
38
Chapter 6
Conclusion
In this thesis, we have designed and implemented security hardening features for the
modern commercial automotive system, AGL, the main purpose of which is to miti-
gate attack impact in case of a compromised operating system when attacker possess
administrator’s privileges. In our approach, we utilized hardware-enforced memory iso-
lation technology, TrustZone, designed for ARM CPUs. Our solution creates a secure
execution environment for trusted applications as well as provides the mechanism to
establish secure interactive sessions between user and application. In addition, we
proposed a technique to mitigate injection of malicious messages into critical commu-
nication component of automotive systems — CAN bus. We evaluated the security
characteristics of our solution by overviewing possible attack scenarios and their coun-
termeasures implemented in the system as well as demonstrated how it helps to ensure
the confidentiality and integrity of protected components.
In future, we hope to improve compatibility with other SoC models and fully implement
CAN bus routing module by adding inspection and filtering of incoming messages.
40
Bibliography
[1] M. Wolf, A. Weimerskirch, and C. Paar. “Security in automotive bus system”. In
Workshop on Embedded Security in Cars (ESCAR), 2004.
[2] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K.
Koscher, A. Czeskis, F. Roesner, and T. Kohno. “Comprehensive experimental
analyses of automotive attack surfaces”. In Proceedings of the 20th USENIX
Conference on Security, 2011, pp. 77–92.
[3] C. Miller and C. Valasek. “Remote exploitation of an unaltered passenger vehicle”.
In Proc. Black Hat, Las Vegas, NV, USA, 2015, pp. 1–91.
[4] M. Hamad, J. Schlatow, V. Prevelakis, and R. Ernst. “A communication frame-
work for distributed access control in microkernel-based systems”. In Operating
Sys. Platforms f. Embedded Real-Time App, 2016.
[5] A. Van Herrewege, D. Singelee, and I. Verbauwhede. “CANAuth - a simple, back-
ward compatible broadcast authentication protocol for CAN bus”. In ECRYPT
Workshop on Lightweight Cryptography, 2011.
[6] L. Guan, P. Liu, X. Xing, X. Ge, S. Zhang, M. Yu, and T. Jaeger. “Trust-
Shadow: secure execution of unmodified applications with ARM TrustZone”. In
41
Proceedings of the 15th Annual International Conference on Mobile Systems,
Applications, and Services, Niagara Falls, NY, USA, 2017.
[7] Alex Wright. “Hacking cars”. In Communications of the Acm 54.11 (Nov. 2011).
[8] D. Eckhoff and C. Sommer. “Driving for big data? Privacy concerns in vehicular
networking”. In IEEE Security and Privacy 12.1 (Jan. 2014), pp. 77–79.
[9] M. Whalen, D. Cofer, and A. Gacek. “Requirements and architectures for secure
vehicles”. In IEEE Software 33.4 (June 2016), pp. 22–25.
[10] W. Gao and T. Morris. “On cyber attacks and signature based intrusion detection
for Modbus based industrial control systems”. In Journal of Digital Forensics,
Security and Law 9.1 (2014), pp. 37–56.
[11] J. Osborn and D. Challener. “Trusted platform module evolution”. In Johns Hop-
kins APL Technical Digest 32.2 (2013), pp. 536–543.
[12] N. Asokan, J. Ekberg, and K. Kostiainen. “The untapped potential of trusted
execution environments on mobile devices”. In International Conference on Fi-
nancial Cryptography and Data Security, Okinawa, Japan, 2013.
[13] A. Wool. “The use and usability of direction-based filtering in firewalls”. In Com-
puters and Security 23 (2004), pp. 459–468.
[14] J. Osborn and D. Challener. “Data exfiltration: A review of external attack vec-
tors and countermeasures”. In Journal of Network and Computer Applications
101 (Nov. 2017), pp. 18–54.
[15] B. Lampson, M. Abadi, M. Burrows, and E. Wobber. “Authentication in dis-
tributed systems: theory and practice”. In ACM Transactions on Computer Sys-
tems 10.4 (Nov. 1992), pp. 265–310.
42
[16] J. Saltzer and M. Schroeder. “The protection of information in computer sys-
tems”. In Communications of the ACM 17.7 (July 1974).
[17] ARM Security Technology. url: http://infocenter.arm.com/help/topic/
com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_
security_whitepaper.pdf (visited on 09/15/2018).
[18] Automotive Grade Linux Platform Debuts on the 2018 Toyota Camry. url: ht
tps://www.automotivelinux.org/announcements/2017/05/30/automot
ive-grade-linux-platform-debuts-on-the-2018-toyota-camry (visited
on 09/15/2018).
[19] Freescale Semiconductor. NXP Semiconductors | Automotive, Security, IoT.
url: https://www.nxp.com/ (visited on 11/30/2018).
[20] Steve Corrigan. Introduction to the Controller Area Network (CAN). url: http:
//www.ti.com/lit/an/sloa101b/sloa101b.pdf (visited on 10/15/2018).
[21] CAN lower- and higher-layer protocols. url: https://www.can-cia.org/can-
knowledge (visited on 10/15/2018).
[22] Standard for Connecting Electric Components of Light Electric Vehicles. url: h
ttp://www.energybus.org (visited on 11/30/2018).
[23] MilCAN. url: https://www.milcan.org (visited on 11/30/2018).
[24] David Paterson. MPC5510 New FlexCAN Module Features. url: https://www.
nxp.com/docs/en/application-note/AN3488.pdf (visited on 10/31/2018).
[25] Linux community. The Yocto Project. url: https://www.yoctoproject.org/
(visited on 10/25/2018).
43
[26] AGL community. AGL Developer Site - meta-agl-demo. url: http://docs.
automotivelinux.org/docs/devguides/en/dev/reference/meta-agl-
demo.html (visited on 10/25/2018).
[27] Genode Labs. An Exploration of ARM TrustZone Technology. url: https://
genode.org/documentation/articles/trustzone (visited on 10/31/2018).
[28] ARM Software. TZC-400 Implementation. url: https://github.com/ARM-s
oftware/arm-trusted-firmware/tree/master/drivers/arm/tzc (visited
on 10/31/2018).
[29] Philip Prushik. Low-Level Graphics on Linux. url: http://betteros.org/
tut/graphics1.php (visited on 11/03/2018).
[30] i.MX 6 Board. url: https://www.nxp.com/support/developer-resources
(visited on 11/30/2018).
[31] ARM. An open source, portable, easy to use, readable and flexible SSL library.
url: https://github.com/ARMmbed/mbedtls (visited on 11/03/2018).
[32] ARM. ARM CoreLink TZC-400 TrustZone Address Space Controller. url: http:
//infocenter.arm.com/help/topic/com.arm.doc.ddi0504c/DDI0504C_
tzc400_r0p1_trm.pdf (visited on 10/31/2018).
44
Appendix A
Yocto Layers
layer priority===================================meta-agl-trustshadow 8meta-security-smack 8meta-security-framework 6meta-app-framework 7meta-qt5 7meta-agl-demo 7meta-freescale 5meta-freescale-3rdparty 4meta-freescale-distro 4meta-oe 6meta-multimedia 6meta-efl 7meta-networking 5meta-python 7meta-filesystems 6meta-ivi-common 7meta-agl 7meta-agl-distro 8meta-agl-bsp 10meta 5meta-poky 5
45
Appendix B
Framebuffer Structures
// dump from include /uapi/linux /fb.h
struct fb_fix_screeninfo {
char id [16]; /* identification string eg "TT Builtin " */
unsigned long smem_start ; /* Start of frame buffer mem */
/* ( physical address ) */
__u32 smem_len ; /* Length of frame buffer mem */
__u32 type; /* see FB_TYPE_ * */
__u32 type_aux ; /* Interleave for interleaved Planes */
__u32 visual ; /* see FB_VISUAL_ * */
__u16 xpanstep ; /* zero if no hardware panning */
__u16 ypanstep ; /* zero if no hardware panning */
__u16 ywrapstep ; /* zero if no hardware ywrap */
__u32 line_length ; /* length of a line in bytes */
unsigned long mmio_start ; /* Start of Memory Mapped I/O */
/* ( physical address ) */
__u32 mmio_len ; /* Length of Memory Mapped I/O */
__u32 accel ; /* Indicate to driver which */
46
/* specific chip/card we have */
__u16 capabilities ; /* see FB_CAP_ * */
__u16 reserved [2]; /* Reserved for future compatibility */
};
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual ; /* virtual resolution */
__u32 yres_virtual ;
__u32 xoffset ; /* offset from virtual to visible */
__u32 yoffset ; /* resolution */
__u32 bits_per_pixel ; /* guess what */
__u32 grayscale ; /* 0 = color , 1 = grayscale , */
/* >1 = FOURCC */
struct fb_bitfield red; /* bitfield in fb mem if true
color , */
struct fb_bitfield green ; /* else only length is
significant */
struct fb_bitfield blue;
struct fb_bitfield transp ; /* transparency */
__u32 nonstd ; /* != 0 Non standard pixel format */
__u32 activate ; /* see FB_ACTIVATE_ * */
__u32 height ; /* height of picture in mm */
__u32 width ; /* width of picture in mm */
47
__u32 accel_flags ; /* ( OBSOLETE ) see fb_info .flags */
/* Timing : All values in pixclocks , except pixclock (of course )
*/
__u32 pixclock ; /* pixel clock in ps (pico seconds ) */
__u32 left_margin ; /* time from sync to picture */
__u32 right_margin ; /* time from picture to sync */
__u32 upper_margin ; /* time from sync to picture */
__u32 lower_margin ;
__u32 hsync_len ; /* length of horizontal sync */
__u32 vsync_len ; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_ * */
__u32 vmode ; /* see FB_VMODE_ * */
__u32 rotate ; /* angle we rotate counter clockwise */
__u32 colorspace ; /* colorspace for FOURCC -based modes */
__u32 reserved [4]; /* Reserved for future compatibility */
};
48
Appendix C
Input Devices
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="EETI eGalax Touch Screen"
P: Phys=
U: Uniq=
H: Handlers=mouse0 event0
B: PROP=0
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=2608000 3
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="max11801_ts"
P: Phys=
U: Uniq=
49
H: Handlers=mouse1 event1
B: PROP=0
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=3
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="mag3110"
P: Phys=
S: Sysfs=/devices/virtual/input/input3
U: Uniq=
H: Handlers=event2
B: PROP=0
B: EV=9
B: ABS=7
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="mma845x"
P: Phys=
S: Sysfs=/devices/virtual/input/input4
U: Uniq=
H: Handlers=event3
B: PROP=0
B: EV=9
B: ABS=7
50
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="WM8962 Beep Generator"
P: Phys=0-001a
U: Uniq=
H: Handlers=kbd event4
B: PROP=0
B: EV=40001
B: SND=6
I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="gpio-keys"
P: Phys=gpio-keys/input0
S: Sysfs=/devices/soc0/gpio-keys/input/input8
U: Uniq=
H: Handlers=kbd event5
B: PROP=0
B: EV=3
B: KEY=1c0000 0 0 0
51
Appendix D
Touch Logger
# include <stdio.h>
# include <stdlib .h>
# include <unistd .h>
# include <fcntl.h>
# include <linux/input.h>
# define EVENT_DEVICE "/dev/input / event0 "
# define EVENT_TYPE EV_ABS
# define EVENT_CODE_X ABS_X
# define EVENT_CODE_Y ABS_Y
# define EGALAX_MAX_X 32760
# define EGALAX_MAX_Y 32760
# define XRES 1024
# define YRES 768
int main(int argc , char *argv [])
{
52
const size_t ev_size = sizeof ( struct input_event );
struct input_event ev;
int fd;
float xscale = ( float ) XRES / EGALAX_MAX_X ;
float yscale = ( float ) YRES / EGALAX_MAX_Y ;
char name [256];
if ( getuid () != 0)
{
fprintf (stderr , "Root required !\n");
return EXIT_FAILURE ;
}
/* Open Device */
fd = open( EVENT_DEVICE , O_RDONLY );
if (fd == -1)
{
fprintf (stderr , "%s is not a vaild device \n", EVENT_DEVICE
);
return EXIT_FAILURE ;
}
/* Print Device Info */
ioctl (fd , EVIOCGNAME ( sizeof (name)), name);
printf (" Reading from :\n");
printf (" device file = %s\n", EVENT_DEVICE );
printf (" device name = %s\n", name);
printf (" scale factor x:%f y:%f\n", xscale , yscale );
while (1)
53
{
ssize_t size;
size = read(fd , &ev , ev_size );
if (size < ev_size )
{
fprintf (stderr , " Device read error \n");
goto err;
}
/* Print coordinates */
if (ev.type == EVENT_TYPE )
{
char evname ;
if(ev.code == EVENT_CODE_X )
{
ev.value = xscale * ev.value ;
evname = ’X’;
}
else if(ev.code == EVENT_CODE_Y )
{
ev.value = yscale * ev.value ;
evname = ’Y’;
}
else
continue ;
printf ("%d: %c = %d\n", ev.code , evname , ev. value );
}
}
return EXIT_SUCCESS ;
54
Appendix E
FlexCAN Message Buffer Data
Structure
typedef struct _flexcan_frame
{
struct
{
uint32_t timestamp : 16; /*!< FlexCAN internal Free -
Running Counter Time Stamp . */
uint32_t length : 4; /*!< CAN frame payload length in
bytes (Range : 0~8). */
uint32_t type : 1; /*!< CAN Frame Type(DATA or
REMOTE ). */
uint32_t format : 1; /*!< CAN Frame Identifier (STD or
EXT format ). */
uint32_t srr : 1; /*!< CAN Frame Type for EXT
frames . */
uint32_t reserve1 : 1; /*!< Reserved for placeholder . */
56
uint32_t code : 4; /*!< Status code. */
uint32_t reserve4 : 4; /*!< Reserved for placeholder . */
};
struct
{
uint32_t id : 29; /*!< CAN Frame Identifier , should be set
using FLEXCAN_ID_EXT () or FLEXCAN_ID_STD () macro . */
uint32_t prio : 3; /*!< Local priority . */
};
struct
{
uint8_t dataByte3 ; /*!< CAN Frame payload byte3. */
uint8_t dataByte2 ; /*!< CAN Frame payload byte2. */
uint8_t dataByte1 ; /*!< CAN Frame payload byte1. */
uint8_t dataByte0 ; /*!< CAN Frame payload byte0. */
uint8_t dataByte7 ; /*!< CAN Frame payload byte7. */
uint8_t dataByte6 ; /*!< CAN Frame payload byte6. */
uint8_t dataByte5 ; /*!< CAN Frame payload byte5. */
uint8_t dataByte4 ; /*!< CAN Frame payload byte4. */
};
} flexcan_frame_t ;
57