itk1699_ATZelektronik_Security_Fachartikel_Sonderdruck_279hoch_Titel_u_Ruecks_mit_engl_RZ3.indd 1 19.09.2016 16:11:57

www.ATZonline.com

extra

Security Engineering – Protection against Attacks

SECURITY Trusted Execution Environments in Vehicles

Imprint: Special Edition in Cooperation with ITK Engineering AG,

Im Lerchenflug 27, 76773 Kuhardt; Springer Vieweg | Springer Fachmedien

Wiesbaden GmbH, Postfach 1546, 65173 Wiesbaden, Amtsgericht Wiesbaden,

HRB 9754, USt-ldNr. DE81148419

Managing Directors: Joachim Krieger, Dr. Niels Peter Thomas

Head of Sales Management (responsible for advertising): Volker Hesedenz

Director Magazines: Stefanie Burgmaier

Editor in Chief: Dr. Alexander Heintzel

Project Management: Mandy Braun

Print: PRINT PRODUKTION-SERVICE, W. Hiese GmbH,

Tilsiter Weg 9, 61273 Wehrheim

Cover Photo: © Tomasz Zajda | Fotolia

© iconimage | Fotolia

Trusted Execution Environments in Vehicles

Trusted Execution Environments (TEEs) can be applied to harden electronic control unit soft-

ware against attackers. ITK Engineering compares existing TEE approaches and highlights their

differences. TEE approaches isolate security-relevant from non-security-relevant software and,

thus, reduce the surface for attacks on security-relevant software components. The presented

classification and assessment of TEE approaches shows that existing TEE solutions differ signif-

icantly with regard to functionality, security properties, and cost.

GROWING ATTACK SURFACE

The increasing connectivity of vehicles results in a growing attack surface, which can be exploited by potential attackers. Recently published attacks allowed attackers to steal vehicles [1], trace the movement of vehicles [2] or even control the vehicle remotely while driving [3]. These examples show that the necessity for adequate security con-trols grows with increasing connectivity. Besides protecting internal and external vehicular communication channels, the communication endpoints (like elec-tronic control units (ECUs)) must be hardened against attacks via software exploits or software manipulation. In particular, an attacker who is able to

compromise an ECU’s software is not only able to manipulate the behavior of the ECU, but can also affect the func-tionality of communication partners by communicating with them on behalf of the ECU. Thus, vulnerable ECU software poses not only a threat to the ECU itself, but also to the overall system.

Hardening software by applying qual-ity assurance measures is limited due to the growing software complexity. Even rigorous code reviews are not suited to prevent exploitable software vulnerabili-ties entirely. In order to achieve a high level of security, software components that are critical for the security of the overall system can be isolated from non-security-relevant software compo-

© Tomasz Zajda | Fotolia

AUTHORS

Dr.-Ing. Jens Köhleris Senior Security Engineer at the

ITK Engineering AG in Rülzheim (Germany).

Henry Förster M. Eng.is Security Engineer at the ITK Engi-neering AG in Rülzheim (Germany).

3

nents. So-called Trusted Execution Envi-ronments (TEEs) allow executing soft-ware-components inaccessible by soft-ware that is executed outside of the TEE, FIGURE 1. This reduces the attack surface of the system, as an attacker who is able to exploit a vulnerability in potentially complex, but not security-relevant soft-ware components, is not able to compro-mise the security-relevant software com-ponents that are executed in the TEE.

To isolate the execution of security-rel-evant and non-security-relevant software components, a variety of TEE technolo-gies exist. These technologies differ sig-nificantly with regard to their security properties, functionality and cost. Due to the variety of TEE approaches, choosing an approach that is suited for a given application scenario is challenging. In this article, we assess and compare TEE approaches to create a decision-making basis that can be used to choose the most suited TEE solution for a given application scenario.

OVERVIEW OF TEE FUNCTIONALITY

Existing TEE technologies can offer a variety of different functionality, FIGURE 2: – Isolated execution of cryptographic operations: A core functionality of TEEs is to restrict the access of com-promised software on cryptographic keys. To achieve that, the memory that is used to store the cryptographic keys is exclusively accessible by the TEE. Cryptographic operations that require access to the keys are executed within the TEE (e.g., encryption techniques)

– Isolated support functionality: TEEs can contain support functionality such as monotonic counters and random number generators with access to pro-tected sources of entropy. In particu-lar, by relying on protected support functionality, attackers are not able to undermine cryptographic approaches by eavesdropping or tampering with the source of entropy.

– Isolated execution of arbitrary soft-ware: Some TEE technologies allow the execution of arbitrary software components. The TEE protects these software components from being tam-pered with by potentially compro-mised software outside of the TEE.

– Isolated memory: Aside from isolated software execution, TEEs can allow to store data isolated from non-securi-

ty-relevant software. Approaches can realise this functionality based on the TEE’s exclusive memory or by apply-ing cryptographic techniques to allow a secure utilization of external memory.

– Secure Boot: Some TEE technologies enforce that only software that was authorised by the manufacturer can be executed outside of the TEE. Thus, attackers are no longer able to manip-ulate or substitute software before execution

– Authenticated Boot: Some TEE tech-nologies exist that continuously moni-tor which software is executed outside of the TEE. Based on this system state, the TEE can assert to third party sys-tems that only authorised software is executed. Furthermore, approaches can make specific services of the TEE – such as reading from secure storage or the execution of cryptographic operations – conditional upon the cur-rent state of the software that is run-ning outside of the TEE.

ATTACKERS AND SECURITY PROPERTIES

Whether a TEE technology provides meaningful protection against an attacker depends on the ability of the attacker to circumvent the security con-trols that have been installed to protect the TEE. The combination of these secu-rity controls form the Trusted Computing Base (TCB). The complexity of the TCB should be as low as possible to prevent vulnerabilities in the TCB.

Without physical access to the hard-ware, attackers can potentially exploit software vulnerabilities to access the system in an unauthorised manner. The consequences of software exploits depend on whether the attacker can compromise components of the TCB. If the attacker is not able to compromise components of the TCB, the security properties of the TEE apply: software components that are executed within the TEE are isolated from software that is executed outside of the TEE. If an attacker is able to compromise compo-nents of the TCB, the isolating properties of the TEE are no longer guaranteed. Thus, the security properties of TEE technologies depend on the implementa-tion of the TCB: – Implementation of the TCB in soft-ware: A TCB that is implemented entirely in software is complex and thus in many cases not formally verifi-able. Consequently, the software-based security controls offer a comparatively large attack surface.

– Implementation of the TCB as a combi-nation of hard- and software: By com-bining software and hardware controls to implement the TCB, the complexity of the potentially vulnerable software controls can be reduced drastically compared to a software-based imple-mentation of the TCB. Thus, the attack surface of exploitable vulnerabilities in software controls can be minimised.

– Implementation of the TCB in hard-ware: If the TCB contains exclusively hardware controls, there is no TCB attack surface from the perspective of

FIGURE 1 Protection against software exploits via Trusted Execution Environments (© ITK)

DEVELOPMENT SEcURITy

4

Security

attackers without physical access to the hardware.

Physical access to hardware enables attackers to make use of additional attack vectors such as reading out mem-ory, desoldering, or reconfiguration of hardware building blocks. Such tech-niques can be used to circumvent TCB controls that are implemented in hard-ware. Enhancing TEE approaches with tamper resistance mechanisms allows avoiding, recognising, or proving hard-ware tampering attacks. In particular, TEE approaches differ with regard to which tamper resistance mechanisms are applicable: – High degree of integration: The attack surface for physical attacks shrinks with a higher level of physical integra-tion of the TEE approach with the sys-tem. In particular, attackers require more specific and expensive tools like scanning electron microscopes if the TCB hardware is integrated in the CPU chip of an ECU than in the case of the TCB hardware being coupled with the CPU via a freely accessible circuit path.

– Side-channel resistance: Some TEE approaches can be supplemented with mechanisms like shielding or noise jamming to make side-channel attacks like power, timing, or electromagnetic radiation analysis more difficult.

– Hardware binding: Some TEE approaches are able to determine

whether the hardware foundation based on which they are executed has been modified. Thus, attacks that require the substitution of hardware with manipu-lated hardware is more difficult.

EXISTING TEE APPROACHES

FIGURE 3 shows a classification of exist-ing TEE approaches with regard to their functionality, security properties and cost. Hardware Security Modules (HSMs) is the generic term for dedicated hard-ware modules that execute software components isolated from software that is executed elsewhere. HSMs can be real-ised as an external module, system-on-chip (SoC) or integrated circuit (IC). A variety of HSM variants exist that differ with regard to their functionality. The most established standardised HSMs are the Secure Hardware Extension (SHE) [4], EVITA HSMs [5], and Trusted Plat-form Modules (TPMs) [6,7]. The stand-ards only specifies the functionality of the HSMs, not the implementation or the amount of resources used: – SHE [4] and EVITA-Light HSMs [5] contain dedicated RAM, ROM, non-volatile memory and a cryp-tographic unit that supports the sym-metric Advanced Encryption Standard (AES) in hardware

– EVITA-Medium HSMs [5] extend the ECITA-Light by a secure CPU. This

allows the execution of asymmetric cryptographic operations inside the HSMs

– EVITA-Full HSMs [5] offer additional hardware acceleration for time-critical, asymmetric cryptography

– TPMs [6,7] are not programmable and only support a fixed functionality – compared to Evita HSMs. In particular, TPMs support symmetric and asym-metric encryption techniques, message authentication codes and hash functions

– Smartcards [8] are embedded, low resource systems with dedicated mem-ory and CPU. Examples for smartcards are access cards in hotels or SIM cards for mobile communication.

CPU security extensions like ARM TrustZone [9] or Intel Trusted Execution Technology (Intel TXT) [10] execute two „worlds“, the so-called Normal World and the Secure World, pseudo-parallel on the same hardware foundation. Hard-ware-based security extensions enforce that applications that are executed in the Normal World cannot access data or periphery of Secure World applications. Thus, the Secure World constitutes a TEE that compromised software from the Normal World cannot affect. In order to call security-relevant software compo-nents in the Secure World from the soft-ware that is executed in the Normal World, a context switch between both

FIGURE 2 Overview of possible TEE functionality (© ITK)

5

worlds is required. CPU security exten-sions implement this context switch in a monitor software component, which is easily verifiable, as it is small and not complex. The Secure World is able to execute arbitrary software components. Furthermore, functionality like secure random number generators as well as secure and authenticated boot can be realised based on the Secure World.

Virtualisation solutions comprise hypervisor solutions like Xen [11] or KVM [12] and operating system virtual-isation solutions like Linux Containers (LXC) [13]. Virtualisation solutions ena-ble an isolated execution of multiple applications or even operating systems on the same hardware. Thus, each appli-cation/operating system is executed in an exclusive TEE that is isolated from other applications/operating systems. As virtualisation solutions do not implement

the isolation based on hardware, the TCB consist of a comparatively complex code base, i.e., the hypervisor in case of hypervisor solutions and a complete host operating system in case of operating system virtualisation solutions. This code base has to be trusted as it is not formally verifiable due to its complexity.

APPLICATION SCENARIOS

Due to their low cost, HSMs that con-form to the Evita-Light / SHE standards are suitable to be applied in ECUs that only make use of symmetric cryptogra-phy and do not have to execute other software components within a TEE. Examples for such ECUs include sensors/actuators that have to secure communi-cation channels.

HSMs that conform to the Evita-Me-dium standard balance the trade-off

between cost and supported functionality. They are particularly suitable for ECUs that act as interconnect for vehicle-inter-nal communication, as they allow a higher data throughput than Evita-Light HSMs due to their hardware-accelerated symmetric cryptography and support for non-time-critical asymmetric cryptography. For instance, Evita-Medium HSMs can be applied in central ECUs or gateways.

HSMs that conform to the Evita-Full standard offer more functionality, but are comparatively expensive. Due to the hardware-accelerated symmetric and asymmetric cryptography, Evita-Full HSMs can execute cryptographic opera-tions with a low latency and are there-fore particularly suited to secure time-critical communications with sys-tems outside of the vehicle.

TPMs are prevalently utilised in IT systems like servers or desktop systems.

FIGURE 3 Comparison of existing TEE approaches (© ITK)

Functionality Security properties Cost

Isol

ated

exe

cuti

on o

f cr

ypto

grap

hic

oper

atio

ns

– S

ymm

etri

c cr

ypto

grap

hy (

SW

)

– A

sym

met

ric

cryp

togr

aphy

(S

W)

– S

ymm

etri

c cr

ypto

grap

hy (

HW

)

– A

sym

met

ric

cryp

togr

aphy

(H

W)

Isol

ated

sup

port

fun

ctio

nality

– R

NG

with

sec

ured

ent

ropy

sou

rce

– M

onot

onic

cou

nter

Isol

ated

exe

cuti

on o

f ar

bitr

ary

soft

war

e

Isol

ated

mem

ory

Sec

ure

Boo

t

Aut

hent

icat

ed B

oot

Pro

tect

ion

agai

nst

phys

ical

att

acks

– H

igh

degr

ee o

f in

tegr

atio

n

– S

ide-

chan

nel

att

ack

resi

stan

ce

– H

ard

war

e b

indi

ng

Pro

tect

ion

agai

nst

non-

phys

ical

att

acks

– Tc

B r

ealiz

ed in

har

dw

are

– Tc

B r

ealiz

ed in

har

d-

and

soft

war

e

– Tc

B r

ealiz

ed in

sof

twar

e

Rel

ativ

e fi

nanc

ial

cost

Pre

vale

nt d

esig

n

Upd

atea

bility

of

th

e so

ftw

are

that

is e

xecu

ted

in t

he

TE

E

Hardware Security Modules

– SHE [4] x x (x) x x (x) x x low Soc / Ic none

– EVITA light [5] x x (x) (x) (x) x (x) x x low Soc / Ic none

– EVITA medium [5] x x x x x x x x x (x) x x low Soc / Ic (SW Update)

– EVITA full [5] x x x x x x x x x x (x) x x medium Soc / Ic (SW Update)

– TPM 1.2 [6] x x x x x x x (x) (x) x high EM none

– TPM 2.0 [7] (x) (x) x x x x x x x (x) (x) x high EM none

– Smartcard [8] (x) (x) x x (x) (x) x low EM (SW Update)

CPU security extensions

– ARM TrustZone [9] x x (x) (x) x x x x x x (x) (x) (x) x low-high

Soc (SW Update)

– Intel TXT [10] x x (x) (x) x x x x x x (x) (x) (x) x Soc (SW Update)

Virtualization solutions

– Hypervisor (e.g., Xen [11]) x x (x) x x (x) (x) x low-high

Software SW Update

– container (e.g., LXc [13]) x x (x) x x x Software SW Update

Legend: x = supported, (x) = optionally supported, not supported; Soc: System-on-chip, Ic: Integrated circuit, EM: Extension module

DEVELOPMENT SEcURITy

6

For most automotive applications, TPMs are considered as too costly and not flex-ible enough with regard to functionality [14, 15].

Smartcards are not embedded in the system. Thus, they are particularly suited as authentication tokens, similar to identification cards of many carshar-ing providers. Due to their low memory and computation resources, smartcards are usually not suited for isolating the execution of complex software or execut-ing cryptographic operations.

CPU security extensions execute soft-ware that is isolated within the TEE on the main processor. Thus, given that the main processor is resourceful enough, CPU security extensions can be used to execute even very demanding software in an isolated environment.

Compared to the other TEE approaches, virtualisation solutions can be retrofitted even if the hardware foun-dation of a system cannot be changed anymore. However, due to the compara-tively high memory and computation overhead, it is reasonable to apply virtu-alisation solutions only on comparatively resourceful ECUs.

CONCLUSION

To ensure an adequate level of security, one has to select carefully a suitable TEE approach based on the threats that have to be addressed and on the TEE func-tionality that is required. In this regard, the proposed classification constitutes a basis for decision-making.

Furthermore, one has to consider that the attack surface of the software that is executed in the TEE grows proportion-ally with the amount of software that is executed in the TEE. The bigger the attack surface is, the higher the probabil-ity is that an attacker can find and exploit software vulnerabilities. Thus, another challenge of applying TEE tech-nologies is to evaluate carefully, which software components are actually securi-ty-relevant and which are not.

REFERENCES[1] D. Spaar, “Auto, öffne dich! – Sicherheitslücken bei BMWs connectedDrive”, http://www.heise.de/ct/ausgabe/2015-5-Sicherheitsluecken-bei-BM-Ws-connectedDrive-2536384.html, 2015[2] Wired.com “your BMW or Benz could Also Be Vulnerable to That GM OnStar Hack”, https://www.wired.com/2015/08/bmw-benz-also-vulnerable-gm-onstar-hack/. 2015.

[3] c. Miller and c. Valasek. “Remote exploitation of an unaltered passenger vehicle.” Black Hat USA (2015) [4] Herstellerinitiative Software (HIS), “SHE Secure Hardware Extension Version 1.1.”, 2009[5] O. Henniger et al., “Securing vehicular on-board it systems: The EVITA project”, VDI/VW Automotive Security conference. 2009[6] Trusted computing Group. “TPM Main Part 1 Design Principles”, Specification Version 1.2. 2006[7] ISO Standard. “ISO/IEc 11889 – Information technology – Trusted platform module library”, (2015)[8] O. Kömmerling, M. G. Kuhn, “Design Principles for Tamper-Resistant Smartcard Processors”, Smartcard 99. (1999).[9] ARM Limited. “Security Technology Building a Secure System Using TrustZone Technology (white paper)”, ARM Limited. 2009[10] J. Greene, “Intel Trusted Execution Technology (white paper)”, http://www.intel.com/txt. 2012.[11] P. Barham et al., “Xen and the art of virtualiza-tion”, AcM SIGOPS Operating Systems Review. 2003[12] A. Kivity et al., “KVM: the Linux virtual machine monitor”, Proceedings of the Linux Symposium. 2007[13] D. Merkel. “Docker: lightweight linux containers for consistent development and deployment”, Linux Journal (239). 2014[14] M. Wolf, T. Gendrullis. “Design, implementa-tion, and evaluation of a vehicular hardware security module”, Information Security and cryptology (IcISc). 2011 [15] M. Kreuzer, c. Wenzel-Benner. “Trusted Plat-form Modules und ihr Beitrag zur sicheren internen Kommunikation von Fahrzeugen”, 29. VDI/VW- Gemeinschaftstagung. 2013

7

ITK Engineering AGHeadquarters: RuelzheimIm Speyerer Tal 676761 Ruelzheim, GermanyPhone: + 49 (0)7272 7703-0Fax: + 49 (0)7272 7703-100info@itk-engineering.com

www.itk-engineering.com www.itk-career.com

Branch offices throughout Germany, ITK companies worldwide

Follow us on:

ITK Engineering AG Stability, reliability and methodological expertise – this is what we have

stood for since our founding in 1994. At all times, our customers have

benefitted from our dedicated multi-industry know-how, especially in the

fields of control systems design and model-based design. Customers can

count on us – from conception through to deployment, we cover the entire

development process.

Our Services include:

Software development

Hardware development

Electrical & electronic systems

System integration

Software as a product

Turnkey systems

Customer specific development

Technical consulting

Seminars

Quality assurance

The satisfaction of each of our partners and mutually respectful cooperation

shape our corporate philosophy, in which four values are firmly anchored:

Read more about this on the web.

itk1699_ATZelektronik_Security_Fachartikel_Sonderdruck_279hoch_Titel_u_Ruecks_mit_engl_RZ3.indd 3 19.09.2016 16:16:13