Using a Certified Hypervisor to Secure V2X communication

Size: px

Start display at page:

Download "Using a Certified Hypervisor to Secure V2X communication"

Ami Cecily McCoy
6 years ago
Views:

1 SYSGO AG PUBLIC 1

2 Using a Certified Hypervisor to Secure V2X communication Author(s): Date: Version Chris Berg 08/05/2017 v1.1 SYSGO AG PUBLIC 2

3 Protecting Assets People started protecting their assets (e.g. life) from the very beginning of their existence People started building Fences Walls Trenches + water Air-gapping SYSGO AG PUBLIC 3

4 Protecting Assets People started protecting their assets (e.g. life) from the very beginning of their existence People started building Fences Walls Trenches + water Air-gapping SYSGO AG PUBLIC 4

5 What is going to be hacked??? SYSGO AG PUBLIC 5

6 Short Answer: The weakest link SYSGO AG PUBLIC 6

7 Long Answer: Attack Surface Typically attacks aim at Components with the exposed interfaces Information flow within system, i.e. component interaction Thus, the attack surface is the full system architecture Security is the integral system property! Without a clean design, it is extremly difficult to identify/define the attack surface SYSGO AG PUBLIC 7

8 Secure Design Principles (Saltzer and Schroeder 75) Design Principle Principle of Economy of Mechanism Explanation The protection mechanism should have a simple and small design. Principle of Fail-safe Defaults Principle of Complete Mediation Principle of Open Design Principle of Separation of Privilege Principle of Least Privilege Principle of Least Common Mechanism Principle of Psychological Acceptability The protection mechanism should deny access by default, and grant access only when explicit permission exists. The protection mechanism should check every access to every object. The protection mechanism should not depend on secrecy of its design The protection mechanism should grant access based on more than one piece of information (e.g., two keys are needed to open a vaultlock or defence in the depth). Every process shall operate with the minimum privileges needed to perform its task Minimize the amount of mechanism common to more than one user and depended on by all users The protection mechanism should be easy to use (at least as easy as not using it). SYSGO AG PUBLIC 8

9 PikeOS Supports Secure Design Principles Design Principle Principle of Economy of Mechanism Principle of Fail-safe Defaults Principle of Complete Mediation Principle of Open Design PikeOS Property PikeOS is 10-15k LoC. Typical hypervisor sizes on market are 60k-200k LoC. That is PikeOS default policy: No information flow and no resource sharing unless specified. PikeOS is a small separation kernel, which controls all accesses to controlled resources. 1) PikeOS source code and design are available for certification needs/vulnerability analysis, i.e. PikeOS security does not depend on secrecy of its design. Principle of Separation of Privilege Principle of Least Privilege Principle of Least Common Mechanism Principle of Psychological Acceptability 2) Detailed PikeOS API documentation available to all customers. PikeOS implements first level privilege, resource level. Thus, system/application design can rely on it and build separate privilege control. PikeOS separation is the technical means to implement it on system level. 1) PikeOS can be the only shared component. 2) PikeOS separation allows modular sharing of system security mechanisms. 1) Decomposition of a system into partitions makes it easier to understand and maintain its functionality. 2) Strong certification portfolio. 9 SYSGO AG PUBLIC 9

10 Agenda Security Challenges Connectivity Automotive Security Separation Kernel Multiple Independent Levels of Security Separation Kernel Security Concept Security Add-On Secure Boot Secure Update Summary SYSGO AG PUBLIC 10

11 Distributed System of ECUs Instrument Cluster Connectivity Box Infotainment Head Unit Electronic Toll Collection Advanced Driver Assistance Systems Ref: Wikipedia SYSGO AG PUBLIC 11

12 Distributed System of ECUs Problems SWaP Size Weight Power Communication overhead, interferences, the cost of interconnect Validation of the integrated system SYSGO AG PUBLIC 12

13 Consolidated System ADAS e.g. Traffic Sign identification Toll Collection ECU State Management... Gateway.. PikeOS Physical Hardware Core 0 Core 1 Core 2 Core 3 SYSGO AG PUBLIC 13

non-real time applications on a single device Shared device

14 Consolidated System Characteristics of Consolidated System Multiple safety levels Multiple security domains Real-time and non-real time applications on a single device Shared device drivers Centralized state management Centralized health monitoring SYSGO AG PUBLIC 14

15 Agenda Security Challenges Connectivity Industrial Security Separation Kernel Multiple Independent Levels of Security Separation Kernel Security Concept Security Add-On Secure Boot Secure Update Security Certification Common Criteria PikeOS Security Certification Summary SYSGO AG PUBLIC 15

16 Why do I want Security? Security for Safety Security for Availability Security vs. Safety Safety The system shall not harm the environment Security The environment shall not harm the system wzjk.jpg&imgrefurl=http%3a%2f%2fwww.spiegel.de%2ffotostrecke%2froboter-sollen-menschen-an- fertigungsstrassen-arbeit-abnehmen-fotostrecke html&h=558&w=850&tbnid=3fzo3ydnbdgxfm%3a&zoom=1&docid=n0rab2uchoonzm&ei=xyzyvfikk8pb7 AbOpICgBw&tbm=isch&client=safari&iact=rc&uact=3&dur=1913&page=2&start=15&ndsp=20&ved=0CE0QrQMw Dw SYSGO AG PUBLIC 16

17 Perfectly Secure Product It is secure because it s doing nothing, i.e. it stays in the same state NOP transition INIT only if initial state is secure SYSGO AG PUBLIC 17

18 Sharing is a Challenge Challenge: Resources sharing Resources CPUs Memory, IO memory Flies, drivers, devices, buses Safety Integrity, availability Isolation, application errors, fail safe Security Integrity, availability, confidentiality Possible side channels via shared resources Resources and API are attack surface Challenge: Time sharing Time CPU cycles Time effects of accessing shared resources, e.g. buses Safety Availability, deterministic behavior, meeting deadlines Right balance between timeand event-triggered tasks Security Availability, confidentiality Possible timing side channels via shared resources, e.g. caches, busses Time is the attack surface SYSGO AG PUBLIC 18

Security by Spatial Separation MMU Map Memory to Partitions

Linux No Error Propagation HMI Android Early Boot CAN-Bus

CBIT Native Privileged Partition Restart / Shutdown Direct

Mode IOMMU Memory access for DMA Devices PikeOS Hypervisor

19 Security by Spatial Separation MMU Map Memory to Partitions Adress- Space Static Configuration of OS Resources Connectivity Linux No Error Propagation HMI Android Early Boot CAN-Bus Guaranteed Access to Assigned Resources System Part. Health Mon. CBIT Native Privileged Partition Restart / Shutdown Direct Mapping of Physical Resources Change Scheduling Execute in User Mode IOMMU Memory access for DMA Devices PikeOS Hypervisor Execute in Kernel Mode Security by separation and controlled information flow SYSGO AG PUBLIC 19

Sharing of L2 Cache and the Consequence Security Domain 1 handling some secret data that shall not leak to Security Domain 2 -> information flow policy requires no data exchange from Dom 1 to Dom 2

20 Sharing of L2 Cache and the Consequence Security Domain 1 handling some secret data that shall not leak to Security Domain 2 -> information flow policy requires no data exchange from Dom 1 to Dom 2 Dom 1 contains an application Transmitter that willingly or non-willingly leaking information to Receiver in Dom 2 Assume: Domain 1 and Doman2 are assigned disjoint resources, e.g. memory Domain 1 and Doman2 are disjoint in time, i.e. executed in different time windows If they are scheduled on same core Core local cache (L1, L2) is shared Cache activity of one domain will be observable from other domain Cache based timing covert channel 20

21 Cache Based Timing Covert Channel Preparation Phase SYSGO AG PUBLIC 21

22 Cache Based Timing Covert Channel Encode Phase; TX Data = 0 SYSGO AG PUBLIC 22

23 Cache Based Timing Covert Channel Decode Phase; RX Data = 0 SYSGO AG PUBLIC 23

24 Cache Based Timing Covert Channel Encode Phase; TX Data = 1 SYSGO AG PUBLIC 24

25 Cache Based Timing Covert Channel Decode Phase; RX Data = 1 SYSGO AG PUBLIC 25

26 Cache Based Timing Covert Channel Maximum Bandwidth Measurement Experiment TX = 0 even set is evicted For RX, tb_e > tb_o TX = 1 odd set is evicted For RX, tb_o > tb_e SYSGO AG PUBLIC 26

27 Cache Based Timing Covert Channel Maximum Bandwidth Measurement Experiment Experiment Configuration TX window size = 350 us RX window size = 350 us Data transferred = 3 MB 9 minutes to transfer 3MB of data bandwidth of 44.6Kbits per second 12 bit Errors SYSGO AG PUBLIC 27

28 Mitigate the Cache Covert Channel Flushing takes variable time based on number of modified lines -> potential timing covert channel Sandwich partition to contain the cache flushing time -> also effective to contain the non-premptable kernel actions taken just before the time partition switch SYSGO AG PUBLIC 28

29 Agenda Security Challenges Connectivity Industrial Security Separation Kernel Multiple Independent Levels of Security Separation Kernel Security Concept Security Add-On Secure Boot Secure Update Summary SYSGO AG PUBLIC 29

30 Secure Boot What am I trying to protect? System availability Reverse engineering/cloning Who am I trying to protect from? Malicious Hacker Customers Competition How do I protect? Implement a chain of trust Encrypt SYSGO AG PUBLIC 30

31 Secure Boot - Implementation Validation Start of an 3 rd and of Application party 3 rd start party applications of applications the loader bootloader PikeOS and Secure image File Provider P Power On 1 Hardware validation Security Engine Bootloader 2 PikeOS PSP Kernel SE 3 3 Validation Module 4 Application Loader 5 5 Partition1: 3 rd party App1 Partition2: 3 rd party App2 FLASH Bootloader and its header PikeOS Image header PikeOS Image 3 rd party Apps 3 rd party App Header SYSGO AG PUBLIC 31

32 Secure Boot - Trusted Chain P Power On 1 Hardware validation Security Engine Bootloader 2 PikeOS PSP Kernel SE 3 3 Validation Module 4 Application Loader 5 5 Partition1: 3 rd party App1 Partition2: 3 rd party App2 FLASH Bootloader and its header PikeOS Image header PikeOS Image 3 rd party Apps 3 rd party App Header SYSGO AG PUBLIC 32

33 Secure Update - Implementation 5 1 Power On 1 Hardware validation Security Engine Bootloader PikeOS PSP Kernel SE Validation Module 4 Application Loader 2 6 Update Manager Partition1: 3 rd party App1 3 FLASH 3 rd party Apps 3 rd party App Header SYSGO AG PUBLIC 33

Security Concept Security Add-On Secure Boot Secure Update Security

34 Agenda Security Challenges Connectivity Industrial Security Separation Kernel Multiple Independent Levels of Security Separation Kernel Security Concept Security Add-On Secure Boot Secure Update Security Certification Common Criteria PikeOS Security Certification Summary SYSGO AG PUBLIC 34

35 Use Case: Secure Gateway PikeOS Native system partition Controls boot process of Linux Implements secure boot Routines for individual partition update Separate partition for secure gateway update ELinOS as Secure IO guest PikeOS Native System Partition Fast Boot Secure Boot Secure Partition Update Esterel graphics ELinOS Secure IO Graph ETH ETH ETH CoreAVI PikeOS i.mx6 External Com TCP/IP with Security patches And updates ETH SYSGO AG PUBLIC 35

36 Microkernel Summary Security is an integral part of the system design Separation There is no on- size-fits-all Separation and MILS help implement system security Certification Hypervisors can implement this separation approach Secure Boot SYSGO AG PUBLIC 36

37 Thank you for your attention! More information on SYSGO AG PUBLIC 37

A Secure Update Architecture for High Assurance Mixed-Criticality System Don Kuzhiyelil Dr. Sergey Tverdyshev SYSGO AG

A Secure Update Architecture for High Assurance Mixed-Criticality System Don Kuzhiyelil Dr. Sergey Tverdyshev SYSGO AG SYSGO AG 1 Secure Software Update Unified Diagnostic Services DiagnosticsSessionControl