real life experience from implementation of firewall ...€¦ · arp/rarp. gptp (ieee 802.1as) ieee...

[email protected], Holle | © ESCRYPT 2019. All rights reserved. Ident: 00TE047 | Version: 04 | State: released | If printed, this document is an uncontrolled copy.

Real life experience from implementation of Firewall, Router and IDS Ethernet switch and uC

Siddharth Shukla, Jan HolleIEEE-SA Ethernet & IP @ Automotive Technology Day, Detroit USA, 25.09.2019

[email protected], Holle | © ESCRYPT 2019. All rights reserved. Ident: 00TE047 | Version: 04 | State: released | If printed, this document is an uncontrolled copy. 8/9/2019 2

Introduction and MotivationSmart Mobility Trends

Selling mobilityinstead of cars

Connectedfunctions

Autonomousdriving

Machine learning

Electro mobility

Big data


Consequences Economic and reputation damage First security-related recall campaign

on 23th July 2015, 1.4 Mio potentiallyaffected vehicles

Mendatory legal requirements

8/9/2019 3

Introduction and MotivationIncreasing Threat Landscape, Regulations & Standardization, Research

Recent remote attack examples 2019 – Tesla Model 3, JIT (Just In Time) 2018 – Volkswagen (Infotainment), BMW 2017 – Tesla Model X, HMC (Bluelink) 2016 – Tesla Model S, Mitsubishi Outlander 2016 – Key relay attack on 19 OEM, 24 Cars 2015 – Jeep Cherokee

“As much as possible,we use network segregation…”

“More importantly, there needs to be real time detection and reaction on vehicle”


Introduction and MotivationTrends in E/E Architecture

Today Tomorrow FutureYesterday

• Many small ECU’s performing a specificfunction

• Signal based communication

• E/E Architecture with support of security features

• Application of service oriented communication and high performance ECUs

• Still cyclic messages being used

• Using ring based network to achieve redundancy

• Introduction of vehicle computers (using security enhanced high performance microprocessors)

• Use of a central Gateway for cross-domain communication

• Security introduction with CAN firewall and SecOCetc.


Introduction and MotivationTodays layered security approaches

Secure in-vehicle communication Protect integrity of critical in-vehicle signals SecOC standardized in AUTOSAR

Secure E/E architecture – establish trust boundaries Use separation and securely configured gateways

to protect functional domains of E/E architecture

Secure connected vehicle Secure Channel (TLS/IPSec), Secure Endpoint Authentication Firewall

Secure individual ECU Hardware security module Protect integrity of ECU software and data Secure Diagnostic/Flashing/Boot

Often, im

plicitly assumed attack

Spoiler: A good defense in depth concept is more than the number of barriers/layers to stop an remote attacker


Real Life experience : Challenges/SolutionZones in EE-Architecture

Infrastructure of Next Gen. EE-Architectures will be shared

Mixed (domain/criticality/trustworthiness/…) applications on zone and vehicle computers and also mixed traffic on backbone and trunk communication links

Selected security challenges

Zone separation Domain based separation or Trusted/Not-trusted model based separation

Virtualization to isolate applications Access control to sensitive (shared) resources Side-Channel attacks on sensitive data,

e.g., on caches to extract cryptographic keys Isolation of Communication, e.g. VLANs Mixed trustworthiness of network nodes Central and local enforcement of

communication policy and access control


Ambiguous border – Where is the (secured) in-vehicle domain?The former, natural separation (caused by the application of different network technologies within and beyond the car) will be less strict in nG EE-Architectures. While separation is still a meaningful and recommended concept, implementation becomes very challenging for upcoming use-cases.

End2End protection vs. Filtering/IDS Many novel use-cases require end2end

protected communication (e.g., privacy or IP) Firewalls and IDS may not be able to inspect An exploit of a potential vulnerability become

effective deeply inside the EE-Architecture

Local interfaces (e.g., Bluetooth, WiFi) Are another (while known) attack avenue

8/9/2019 7

Real Life experience : Challenges/SolutionDefinition of Trust Boundaries – Where is the Endpoint?


Intrusion Detection SystemFull system overview

SIEMEvent Database

Analysis Framework

Attack: Misuse of 0-day exploit in web browser

4

2

1

5

6

Security is not absolute: The OEM’s secure flashing implementation was vulnerable and the attacker was able to flash and run arbitrary code, e.g., in order to send malicious signals.

Intrusion Detection: The in-vehicle IDPS solution detects the anomaly (i.e., potential attack) on the in-vehicle network, it creates and sends an Intrusion Detection Report

Monitoring & Analysis: The IDPS backend collects all anomaly reports from the vehicle fleet and enables security analysts and forensic specialist to analyze the attack and identify the vulnerabilityIntrusion Prevention: A security updateto remedy the vulnerability will be deployed to the entire vehicle fleet

Connected Fleet

3 Firewall: The filtering mechanisms blocks illegitimate signals, e.g, from an invalid source, and informs the IDS. The attacker is not able to control other ECUs.

1

2

3

4

5

6

6


Real Life experience : Challenges/SolutionSwitch thinks it’s a new packet!

Firewall, IDS and Routing Software

Real Time Operating System (RTOS)

Switch CPU

FirewallHardwareConfiguration

Switch CoreIn

tern

al P

ort

Registers

Port

1

Port

2

Port

3

Port

4

Port

5

Port

6

Port

7

Port

8

Port

3 to

Por

t 5

Pack

et

Proc

essin

g

-


Switch CPU


Switch Core

Inte

rnal

Por

t

Registers

Port

1

Port

2

Port

3

Port

4

Port

5

Port

6

Port

7

Port

8

Port

3 to

Por

t 5

Gateway CPU

Ethe

rnet

Por

t

CAN Bus

Packet Processing

New packet for Switch

core

Switch handles this processed packet as new packet Floods to all vlan members



Real Life experience : Challenges/SolutionDynamic configuration update during runtime

Secure/Safe update of policy during runtime Host uC requests Firewall policy update during

runtime e.g. activate a rule during diagnostic session Policy needs to be linked to one or multiple

vehicle states Is the message requesting policy update

authentic and integrity protected?



Switch CPU


Switch Core

Inte

rnal

Por

t

Registers

Port

1

Port

2

Port

3

Port

4

Port

5

Port

6

Port

7

Port

8

Gateway CPU

Ethe

rnet

Por

t

CAN Bus

Pack

et

Proc

essin

g

• GW CPU requests temporary update of

Policy

• Communicates vehicle state

New requirements? HSM inside switch Encryption/Decryption

module in Switch hardware or CPU


Real Life experience : Challenges/SolutionMultiple TCAM rules match one connection

Best practice Sorting of data before configuration Automatic rule generation Sanity check of configuration if rules

updated dynamically

TCAM is just a memory A whitelist/blacklist entry can

match multiple TCAM rules but it will hit the first rule from top More complexity when TCAM

hardware rules are linked to firewall software Unexpected network behavior if

the TCAM policy is updated dynamically during runtime


Real Life experience : Challenges/SolutionMAC Address handling by Central gateway

Solution Hardware assisted

translation Add security to allow

end to end NDP

End to End NDP request is not allowed by ECU’s MAC address

translation for every message adds latency

* NDP:Neighbour Discovery Protocol


Real Life experience : Challenges/SolutionSecure switch configuration/start-up/boot up time

Possible solutions Secure boot Encrypted boot Secure key storage Hardware encryption/decryption

engine Loading of partial configuration

followed by full configuration

Switch needs to store secure configuration Boot over SPIO flash could be

slow Boot over Ethernet requires the

host CPU to boot first Challenging start-up time

requirements

Firmware Update

Secure Boot

AVB Stream Config.

gPTPStack

Custom user Software (optional

Ethernet Firewall, IDS and Routing Software

(Use it as a library or standalone unit)

APPLICATION API(This API is used to build firewall application software)


Switc

h CP

UO

ptio

nal

Optional

Firewall Switch ConfigurationFirewall PrefiltersFirewall VLAN ConfigurationMAC Table Configuration

Switch Core

Inte

rnal

Port

Registers

Port

1

Port

2

Port

3

Port

4

Port

5

Port

6

Port

7

Port

8

SMI

SPI

FLASH

Secure Boot module

Seco

ndar

y Pa

rtiti

on

(Bac

kup)

Prim

ary

Part

ition

Configuration Data

Firmware Image

Configuration

Firmware

Partial configuration


Real Life experience : Challenges/SolutionZone/Traffic Separation & Inspection

Best practice Try to have software traffic separation also in

switch CPU Helpful typically for traffic from Untrusted

port like DoIP No interference on normal communication if

traffic flooding on untrusted port

Zone separation can be implemented using VLANs Software memory

separation easily possible in host CPU

VLAN A VLAN B


Real Life experience : Challenges/SolutionBoundary between Firewall and IDS on Ethernet

Ethernet has too many protocols Has bigger header size

compared to CAN therefore needs more time to inspect header Latency/Bandwidth is a

problem when inspecting headers at higher layer What should be the

boundary between IDS and Firewall?

Presentation

Session

Transport

Network

Data

Application

Prioritization(Fast vs Normal)

DPI of any Depth Logging

IntrusionDetection System

Dynamic ARP

ProtectionIngress Filters Firewall for Smart Charging

FW FW FW FW FW FW FW FW FW FW FW FW FW

UDP-

NM

Bonj

our

SOM

E/IP

SD

XCP

SecO

C

DoIP

PDU

Filte

r

HTTP

(S)

DNS

HSFZ

DHCP

v4/

v6

SSH

UDP Firewall Port NAT TCP Stateful Firewall ICM

P v4

/v6

NDP

UDP UDP/TCP(D)TLS

IP Address Firewall IP NAT DDoS VACL

IP Version 4, 6IPSec

IP Address Firewall

Physical

MAC filter Broadcast Storm Protection

MAC Translation (Layer 2 NAT) CPU Authenticated MAC Learning

ARP/

RARP

gPTP

(IEEE

802

.1AS) IEEE

1722

.1

DPI

AVTP

(IEE

E 17

22)

RTP

(IEEE

1733

)

ISO15118-1

DPI

ISO15118-2

ISO15118-3

100(0) BASE – T1/TX

VLAN (IEEE 802.1Q)Port Tagged Private Subnet Protocol

PNAC (IEEE 802.1 X)MACsec (IEEE 802.1AE) IEEE 802.1 Qci

Per Stream Filtering and Policing


Real Life experience : Challenges/SolutionBoundary between Firewall and IDS on Ethernet

FIREWALL “Fast Lane” very little delay in

processing packets Stateless SOME/IP can be part of the

fast lane, because we can drop packets

NIDS FIREWALL

Switc

h or

CPU

SW Counters

Tree-based

SF/BA SOME/IP

SF/BA DoIP

Communication

Har

dwar

eSo

ftwar

e

TCAMHW Counters

Configuration Configuration

Interface

TCP States

SW ModulesSOME/IP

SL

?BA TCP/UDP

IDS “Slow Lane” Behavioral Analysis (BA) on TCP/UDP Detailed logging Application layer inspection (SOME/IP,

DoIP etc.)

Where to implement Implement load balancing and

distribution Do as much as possible in the switch,

rest in external microcontroller


No interference with host microcontroller or embedded ECU

High performance can be achieved with a good hardware/software co-design

Application of security measures on switch controller using the integrated hardware security features E.g., secure boot, secure key storage

Secure update configuration of update Secure and central management of firewall,

routing, and TSN/AVB configuration Complete packet flow can be maintained from one place

8/9/2019 17

Possible Solution of an Efficient Firewall / IDPSImplementation on Ethernet Switch in a Central Gateway

Implementation on Ethernet Switch Processor


Possible Solution of an Efficient Firewall / IDPSFirewall / IDPS Implementation in a Future Zone-based E/E Architecture

Distribution: Development of a (fully) distributed in-vehicleIDPS and Firewall solution

Scalability: Load-balancing on arbitrary E/E-Architectures Dynamic: Adaptable configuration considering use-cases as,

e.g., MAC address learning and IEEE 802.1X Actuality: Integration of new standardizations (e.g., TSN)

or additional protocols possible Machine Learning: Sophisticated anomaly detection Fleet Monitoring: Maintain an overview about the fleet’s welfare Protection: Real-time protection and reaction considering safety concerns Flexibility: secure updates of Firewall/IDPS rulesets able to support use-cases as, e.g.,

variant management and feature activation


Automotive Ethernet - Opportunities and Challenges for Automotive SecurityFirewall / IDPS Implementation in a Future Zone-based E/E Architecture

Future IDPS will be a fully distributed (virtually installed on every ECU) multi-platform solution

Central rule-based IDS (for single ECU instance)

Most likely on gateways or other µC based ECUs

Distributed rule-based IDS Collaboration and load-balancing

between multiple IDS instances in the vehicle

Distributed self-learning IDS Multi-Network and Multi-Platform

distribution among heterogenECU architectures

Development of a (fully) distributed in-vehicle IDPSSelf-learning intrusion detection mechanisms for Automotive EthernetSupport for non µC based platforms, e.g. POSIX RTEs (Linux or QNX, cf. Adaptive Autosar)

2018 2020 2030


Holistic security

Remotely connected, autonomous driving

“We secure the connected world.”

UnprotectedInterface

QUESTIONS?


ESCRYPT GmbHHeadquarters

Wittener Straße 4544879 Bochum

Germany

Phone: +49 234 43870-200Fax: +49 234 43870-211

[email protected]

Slide Number 1Slide Number 2Slide Number 3Slide Number 4Slide Number 5Slide Number 6Slide Number 7Slide Number 8Slide Number 9Slide Number 10Slide Number 11Slide Number 12Slide Number 13Slide Number 14Slide Number 15Slide Number 16Slide Number 17Slide Number 18Slide Number 19Slide Number 20Slide Number 21

real life experience from implementation of firewall ...€¦ · arp/rarp. gptp (ieee 802.1as) ieee...

Documents